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PREFACE 



This publication contains detailed information necessary to design 
and prepare application programs to execute under three IBM program 
products: CICS/DCS-ENTRY, CICS/DOS-STANDARD, and CICS/OS-STANDARD 
V2. It provides application programmers, system programmers, system 
analysts, and system administrators with information concerning real- 
time application programming considerations, application program 
organization, storage definition, the use of CICS macro instructions 
to reguest supervisory and data management services, data base 
considerations, and program testing and debugging. 

Throughout this publication, parentheses are used in the notation 
of CICS macro instructions to indicate those operands where more than 
cne applicable parameter can be specified with a single use of the 
operand. Where parentheses are not used, only one parameter at a time 
can be specified as part of the operand. An asterisk in (card) column 
72 indicates that the macro instruction is continued on the next line 
(card) . The first operand on a continuation card must begin in column 
16. 

The words "transaction" and "task" have the same connotation in 
CICS and are used interchangeably throughout this publication; the 
processing of a transaction may involve the execution of one or more 
"programs". 

For further information concerning CICS, see the following IBM 
publications: 

General Information Manual (GH20-1028) 
System Programmer's Reference Manual (SH20-1043) 
Terminal Operator's Guide (SH20-1044) 
Operations Guide (CICS/DOS) (SH20-103U) 
Operations Guide (CICS/OS) (SH20-10U8) 
Logic Manual (CICS/DOS- ENTRY) (LY20-0712) 
Logic Manual (CICS/DOS-STANDARD) (LY20-0713) 
Logic Manual (CICS/OS-STANDARD V2) (IY20-0714) 

All references to CICS/OS and CICS/OS-STANDARD in this publication 
are references to the CICS/OS-STANDARD V2 system. 
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INTEODUCTION 



The IBM Customer Information Control System (CICS) is a 
multi-application data base/data communication interface between a 
System/360 or System/370 operating system and user-written application 
programs. Applicable to most online systems, CICS provides many of 
the facilities for standard terminal applications: message switching, 
inguiry, data collection, order entry, and conversational data entry. 

Functions performed by CICS include: 

• Control of a mixed telecommunications network 

• Concurrent management of a variety of programs 

• Controlled access to the data base 

• Management of resources for continuous operation 

• Prioritization of processing 

By eliminating many of the development reguirements for such 
functions of a real-time control system, CICS allows programmers to 
concentrate instead on implementing applications, dramatically reducing 
implementation time and cost. 

Functions needed to support a data base/data communication system 
and standard terminal applications are provided by the following CICS 
management functions: 

• Task Management - Provides its own dynamic multitasking facilities 
necessary for effective, concurrent transaction processing. 
Functions associated with this facility include priority scheduling, 
transaction synchronization, and control of serially reusable 
resources. This CICS function is in addition to the multitasking 

or multiprocessing capability of the host operating system. 

• Storage Management - Controls main storage allocated to CICS. 
Storage acguisition, disposition, initialization, and reguest 
gueuing are among the services and functions performed by this 
component of CICS. 

• Program Management - Provides a multiprogramming capability through 
dynamic program management while offering a real-time program fetch 
capability. 

• Program Interrupt Management - Provides for the interception of 
program interrupts by CICS to prevent total system termination. 
Individual transactions that program check are terminated by CICS 
with a dump (if Dump Management is used) , thus preventing the entire 
CICS partition/region from terminating. Under CICS/OS, supports 
the runaway task control function of CICS Time Management. 

• Time Management - Provides control of various optional task 
functions (system stall detection, runaway task control, task 
synchronization, etc.) based on specified intervals of time or the 
time of day. 

• Dump Management - Provides a facility to assist in analysis of 
programs and transactions undergoing development or modification. 
Specified areas of main storage are dumped onto a seguential data 
set, either tape or disk, for subseguent offline formatting and 
printing using a CICS utility program. 



• Terminal Management - Provides polling according to user-specified 
line traffic control as well as user requested reading and writing. 
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This facility supports automatic task initiation to process new 
transactions. The testing of application programs is accommodated by 
the simulation of terminals through seguential devices such as card 
readers, line printers, disk, tape, etc. 

• File Management - Provides a data base facility using direct access 
and indexed seguential data management. This function supports 
updates, additions, random retrieval, and selective retrieval 
(browsing), of logical data on the data base. Optional access to 

the Data Language/I (DL/I) facility of the IBM Information 
Management System (IMS/360) is also provided under CICS/OS. Use 
of DL/I reguires installation of the IMS/360 Version 2, Modification 
Level 2 (or later) Data Base System (5734-XX6) . 

• Transient Data Management - Provides the optional gueuing facility 
for the management of data in transit to and from user defined 
destinations. This function facilitates message switching, data 
collection, and logging. 

• Temporary Storage Management - Provides the optional general purpose 
"scratch pad" facility. This facility is intended for video display 
paging, broadcasting, data collection suspension, conservation of 
main storage, retention of control information, etc. 

In addition to these management functions, CICS provides system 
service programming to identify 'terminal operators, to give dynamic 
control of the entire system to a master terminal, to display real-time 
system statistics, to intercept abnormal conditions not handled directly 
by the operating system, to provide basic mapping support for the 3270 
Information Display System, and to end operation by gathering summary 
statistics, closing data sets, and returning control to the operating 
system. 
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JE AI-TIME AMPLICATION PROGRAMMING 

In the conventional batch processing environment, the application 
programmer plans a series of runs to edit batches of input transactions, 
update master files (data sets) , and write output reports. To optimize 
total run time and streamline the cycle, he must concentrate on careful 
manipulation of data. In accomplishing this, the data becomes 
intricately tied to his program logic and is of little value to other 
applications. 
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Figure 2. Transaction processing of CICS 



In the past, the successful systems have been known as: 

• Online information systems 

*• Real-time informational systems 

• Teleprocessing systems 

• Data base/data communication systems 

These systems required the user to develop a control system that would: 

• Host a telecommunication network of mixed devices 

• Concurrently manage a wide mixture of transactions being serviced 
by a variety of programs 

• Provide effective controlled access to the data base 

• Effectively manage resources, such as main storage, to keep the 
system in continuous operation 

• Prioritize the use of the processing facility 

• Provide other real-time facilities necessary for the support of 
the applications and tie environment 

• Provide the ancillary system service functions necessary for the 
successful implementation of data base/data communication systems 

• Provide rapid response to the terminals 

CICS solves many of these complexities for the application programmer 
ty managing data centrally (in a data base) on behalf of all 
applications. This shifts the burden of system management 
considerations from the application programmer to the system programmer 
and allows the application programmer to concentrate instead on the 
application. 

A key consideration in the selection of a data base/data 
communication system is that it be appropriate for today's needs and 
have the growth potential that characterizes the DE/DC environment. 
CICS is intended to address precisely that consideration; that is, 
CICS is a family of systems that provides a DB/DC interface to the 
IBM System/360 and System/370 at most levels of the product line, 
providing a clearly visible growth or migration path as the user's 
environment dictates. 



Figure 3 shows how the CICS data base supports the information needs 
of each application, independently and concurrently. 
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Figure 3. CICS data base concept 



EBOGRAM STRUCTURE 

The user's application programs are processed concurrently by CICS 
as transactions (tasks) . Although application programs may be as large 
as 32K bytes, it is recommended that each application program be 
developed modularly and kept to a minimum sitie. Large application 
programs can prevent the loading of other required programs during 
the operation of CICS and thus degrade the overall system performance. 

CICS facilitates the modularity of application programs by allowing 
programs to easily communicate with other programs through the execution 
of CICS macro instructions. Since application programs do not contain 
input/output areas or transaction work areas, a 4K application program, 
when assembled, could contain as many as 1000 machine instructions. 

Application programs can be written in Assembler language, ANS 
COBOL, or PL/I to execute under CICS. Regardless of the language used, 
it is strcngly recommended that the application programmer allow CICS 
to perform all supervisory and data management services for his 
applications by issuing CICS macro instructions to invoke the desired 
services. Although the application programmer is not precluded from 
direct communication with the operating system, the results of such 
action are unpredictable and performance may be affected. Such action 
would also have a limiting effect on migration from CICS/DOS to CICS/OS, 
if this were ever desired. 

An application program written in PL/I must consist of an external 
(MAIN) procedure. Internal procedure CALL'S are allowed in a CICS 
program; external CALL'S are not. 

COAST-REENTRANCE 

Application programs must be coded so that they are "serially 
reusable" between entry and exit points of the program. Entry and 
exit points of an application program coincide with the use of CICS 
macro instructions, since an application program temporarily loses 
control after it begins executing only upon execution of a e CICS macro 
instruction. A serially reusable portion of an application program 
is executed by only one transaction at a time, and must initialize 
and/or restore any instructions or data that it alters within itself 
during execution. 

This required quality of application programs written to run under 
CICS is called "quasi-reentrance", since the programs need not meet 
System/360 or System/370 specifications fcr true reentrance. Quasi- 
reentrance allows a single copy of a user-written application program 
to be used to process several transactions concurrently, thereby 
reducing the requirement for multiple copies of the same program in 
main storage. 

If intermediate exits are taken in an application program, all 
switches, data, and intermediate results needed upon subsequent return 
to that transaction must be retained in a unique storage area such 
as the Transaction Work Area (TWA) . The application programmer must 
provide that unique intermediate storage area by symbolically defining 
it in his program (as described in the section on "Symbolic Storage 
Definitions") . 

a serially reusable application program that has no intermediate 
exits also has the quality of quasi-reentrance. 



CICS TRANSACTION FLOW 

CICS executes in a multitasking mode of operation. Therefore, 
whenever a transaction (task} is waiting for I/O completion, other 
CICS transactions may continue to execute. 

Figure 4 illustrates CICS multitasking where the same application 
program is used by three different transactions (A, B, and C) . The 
application program performs a data base read and a subsequent write. 
Solid lines indicate that the transaction is executing; broken lines 
indicate that the transaction is waiting. 



/$■' 



& 



£ 



<$ 












% 
& 



<*> 






<</ 



AT 



Or 



4? 






<V 



<< 



/S' 



# 





















# 
^ 



Co 



*S 



.# 






£ 






■<<S 






<<r 



c 






•S^ 



& 



<o A? 



c§^# 



/V 



# 















<«. 












TASK A 
TASK B 
TASK C 









- 


-- 
















- 


-- 
























-- 














— 


- 


__ 















Figure 4. CICS multitasking 



Figure 5 illustrates the logical flow of a typical transaction 
through CICS. 
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Figure 5. CICS transaction flow 



APPLICATION PPOGBAM ORGANIZATION 



STORAGE DEPIJITICN 

The source library supplied with CICS contains symbolic storage 
definitions cf CICS control areas, work areas, and I/O areas. It is 
strongly recommended that the application programmer use these 
definitions in his programming rather than develop actual or direct 
displacements. This protects the application program in the event 
cf any relocation of CICS. 

For the PI/I programmer, the source library contains numerous BASED 
structures of CICS control areas. These dummy sections are available 
to the user through use of the %INCLUDE statement. The ANS COBOL 
programmer makes use of these definitions through use of the COPY 
statement in the Linkage Section of the Data Division. These 
definitions are discussed in the Storage Definition section of this 
manual. 



PROGRAM INITIALIZATION 

In the initialization section of the application program, the 
application programmer must establish a symbolic base address for his 
program as this is not done by CICS prior to entry. Register 12 is 
reserved by CICS to contain the address of the Task Control Area (TCA) 
for this task. Register 13 is reserved to contain the address of the 
Common System Area (CSA) . These registers are initialized by CICS 
prior to entry and must b€ preserved throughout the execution of the 
program. Por ANS COBOL and PL/I, this situation is resolved by CICS 
and is of no concern to the application programmer. 

Registers 15 through 1 1 are available to the user and are kept 
intact when a CICS macro instruction is issued; the contents of register 
14 are destroyed any time a CICS macro instruction is issued. 

The status of all registers upon program entry or upon return to 
a program is as fellows: 
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Note: Even though register 14 contains the program entry address, 
it is not advisable to use register 14 as the base register 



since it is used by CICS to service requests for CICS supervisory 
and data management services. 

SERVICE INVOCATION 

ASSEMBLY TIME SERVICE 

The DFHCOVER macro instruction is used to request the Assembler 
cr Compiler to print a cover page on two consecutive pages. In this 
way, the application program listing may be torn off with one of the 
cover pages face up. Pertinent information (for example, program name, 
date, time of assembly, remarks, etc.) may then be written on the cover 
page. 

The DFHCOVER macro instruction requires no operands and should 
appear with nothing else en the card. 

If the DFHCOVER macro instruction is coded as part of an application 
program written in Assembler language, it should be coded as the first 
instruction in the program. If desired, however, this macro instruction 
may be coded after anything that is not vital to the listing (such 
as the TITLE card) . 

If the DFHCOVER macro instruction is coded as part of an ANS COBOL 
application program, it should be coded preceding the IDENTIFICATION 
DIVISION card. 

The PL/I Compiler prints the first card of the source deck as a 
header on each page of the source listing. This means that when the 
DFHCOVER macro instruction is part of a PL/I application program, the 
first card should be a Comments Card containing information the 
application programmer wants printed as a header. The second card 
should contain the DFHCOVER macro instruction. The actual PL/I code 
should begin on the third card of the source deck. 

Since column 1 is used by the DFHCOVER macro for line and page 
spacing under PL/I, column 1 must be defined as reserved for control 
characters and columns 2-72 must be defined as available for data. 
This is accomplished through the *PROCESS card for CICS/DOS and the 
EXEC card for CICS/OS. For further information concerning PL/I compile- 
time services, see the publication DOS PJL/I Optimizing Compiler 
Programmer's Guide (SC33-C008) or the publication OS PL/I (F) 
Programmer's Guide (GC28-6594) . 

The examples contained in Appendix A shew how the DFHCOVER macro 
instruction is used. 

SUPERVISORY AND DATA MANAGEMENT SERVICES 

The various CICS supervisory and data management services are invoked 
through use of CICS macro instructions. These macro instructions are 
written in Assembler language and, as all Assembler language 
instructions, are written in the following format: 

Name. Operation Operands Comments 

blank DFHixxxx One cr mere operands 

or separated by commas 

symbol 

The name field of a CICS macro instruction must be left blank if 
the macro instruction is used in conjunction with a high-level language 

10 
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(ANS COBOL or PL/I) ; if a label is desired for the macro instruction, 
it may be placed on the card preceding the macro instruction. 

The operation field of a CTCS macro instruction must begin before 
card column 16 and must contain the three-character combination "DFH" 
in the first three positions of the operation field. Dp to five 
additional characters can be appended to DFH to complete the symbolic 
name for the appropriate program or table. Since DFH is reserved for 
CICS macro instructions, no other statement may begin with this 
three-character combination. 

The operand field of a CICS macro instruction contains one or more 
operands separated by commas. In this publication, parentheses are 
used to indicate those operands where more than one applicable parameter 
(keyword and otherwise) can be specified with a single use of the 
operand. Where parentheses are not used, only one parameter at a time 
can be specified as part of the operand; a choice must be made in the 
case of more than one applicable parameter. Since a blank character 
indicates the end of the operand field, the operand field must not 
contain blanks except after a comma on a continued card or after the 
last operand of the macro instruction. The first operand on a 
continuation card must begin in column 16. 

When a CICS macro instruction is coded on more than one card, each 
card containing part of the macro instruction (except the last card) 
must contain a character (for example, an asterisk) in column 72 
indicating that the macro instruction has been continued on the next 
card. 

See the section "Service Invocation" later in this publication for 
a detailed description of how CICS macro instructions are used to 
request CICS supervisory and data management services. See Appendix 
B for a listing of the CICS macro instructions that may be used by the 
application programmer. 

The use of CICS macro instructions in a PL/I application program 
precludes the use of the following PL/I features: 

1. The multitasking functions: COMPLETION, STATUS, PRIORITY. 

2. The multitasking options: PRIORITY, TASK, EVENT, REPLY. 

3. The PL/I statements: READ, WRITE, GET, PUT, OPEN, CLOSE, 
DISPLAY, SORT, DELAY, ON. 

The use of CICS macro instructions in a PL/I optimizing compiler 
application program also precludes the use of the following options: 

1. REPORT, FLOW, GONUMBER, GOSTMT. 

The use of CICS macro instructions in an ANS COBOL application 
program precludes the use of the following ANS COBOL features: 

1. Environment and Data Division entries normally associated with 
the data management services. 

2. File Section of the Data Division. 

3. Special features: SORT, REPORT WRITER, SEGMENTATION, EXHIBIT, 
TRACE, DISPLAY, and ACCEPT. (DISPLAY and ACCEPT can be used in 
conjunction with the system console.) 

4. Options that may lead to the issuance of a STXIT (AB) SVC or 
STAE SVC: FLOW, STATE, STXIT, or SYMDMP for CICS/DOS; FLOW or 
STATE for CICS/OS. 

Separate ANS COBOL routines or separate PL/I routines may not be 
link edited together. Separate Assembler-language routines may be link 
edited together, however, the CALLed routine must conform to CICS 
application program requirements. CICS provides the user with the LINK 
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and XCTL (transfer control) facilities to provide the necessary 
communication between programs. CICS macro instructions should not be 
coded within an ANS COBOL statement, since each ANS COBOL statement 
generated by a CICS macro instruction is terminated by a period. 
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STORAGE DEFINITION 



SYMBOLIC STORAGE DEFTJITTCNS 

CICS defines a number of main storage areas which the application 
program can use during execution. These storage areas are of three 

types: 

1. Ccntrcl areas 

2. Work areas 

3. Input/output areas 

Information is stored and retrieved from these areas by CICS and ty 
application programs. 

Some of the storage areas are statically created by CICS during 
System Initialization and others are dynamically acguired and released 
during execution of the system. Some of the areas are acguired or 
created by CICS; seme are acguired directly by the application program; 
and some are acguired by both CICS and the application program. 

All CICS storage areas, with the exception of the Terminal Control 
Table terminal entry (TCTIE) , consist of two logical and unigue 
sections. The control section is used primarily by CICS; the user's 
section is defined and used exclusively by application programs. This 
logical division always exists except for the TCTTE, whether the storage 
is statically created (for example, the Common System Area) or 
dynamically acquired (for example, a Terminal Input/Output Area) . 

CICS provides a set cf symbolic storage definitions (dummy sections) 
to describe the layout of the control section of all the applicable 
storage areas. These storage definitions are contained in the CICS 
litraries and, when combined with a user-defined layout of the user's 
section cf the storage areas, provide symbolic addressing to the storage 
areas. 

The Storage Accounting field is perhaps the most important field 
in the control section of the CICS storage areas. (See "Storage 
Accounting Area" below.) This field, present in all CICS storage areas 
except the CSA and TCTTE, is always located in the first eight bytes 
cf every storage area. 

Note: The application programmer must be aware that the Storage 

Accounting field exists in all dynamic storage he acquires, 
and he must take particular care not to alter or destroy the 
information in it. If the information is altered or destroyed, 
an abnormal termination of CICS occurs. 

Two of the ccntrcl areas, the Common System Area (CSA) and the Task 
Control Area (TCA) , are required to be symbolically defined in every 
application program; the third control area (TCTTE) , the work areas, 
and the I/C areas are selected at the option of the user. It is the 
user's responsibility to copy symbolic storage definitions into his 
prcgram for the reguired control areas as well as for any of the other 
storage areas he requires. Figure 6 lists the CICS storage areas, 
indicating which are control areas, which are work areas, and which 
are I/O areas; it also indicates which are acquired by the user and 
which are acquired by CICS. 
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ACQ'D 


ACQ'D 




CONTEOI 


WORK 


I/O 


BY 


BY 




AREAS 


AREAS 


AREAS 


USER 


CICS 






— » _ «1r «.. 


_.»_.*»_ 


— — — ™ — 


" " ' ' 


Common System Area (CSA) 


X 


X 






X 


Task Control Area (TCA) 


X 








X 


Transaction Work Area (TWA) 




X 






X 


File Work Area (FWA) 




X 






X 


Storage Accounting Area (SAA) 




X 




X 




Terminal I/O Area (TTOA) 






X 


X 


X 


Transient Data Input Area (TDIA) 






X 




X 


Transient Data Output Area (TEOA) 






X 


X 




Temporary Storage I/O Area (TSIOA) 






X 


X 


X 


File I/O Area (FIOA) 






X 




X 


Terminal Control Table 












Terminal Entry (TCTTE) 


X 








X 



Figure 6. CICS storage areas 

Depending on the programming language used, one of the following 
statements is reguired to copy a symbolic storage definition into an 
application program. 

1. Assembler language COPY statement of the form: 

COPY name 

2. ANS COBOL COPY statement of the form: 

01 name COPY name, 
specified in the Linkage Section of the Data Division 

3. PL/I preprocessor statement of the form: 

% INCLUDE (name) ; 

In addition to copying the appropriate symbolic storage definitions 
into his program, the application programmer must establish 
addressability for these storage definitions. He does this by 
specifying a symbolic base address for each storage area, thereby 
effectively mapping the symbolic storage definition over the storage 
area. Depending on the programming language used, one of the following 
statements must be used to establish addressability after the dynamic 
main storage has been acguired: 

1. Assembler language statement of the form: 

L symbolic base address register, TCASCSA 

2. ANS CCBCL statement of the fcrm: 

MOVE TCASCSA TO symbolic base address. 

3. PL/I based pointer variable of the form: 

symbolic base address=TCASCSA; 

TCASCSA is a four-byte field that contains the address of the dynamic 
main storage area that was acquired. 
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Figure 7 contains the symbolic names used in copying the storage 
area control section definitions and the symbolic base addresses used 
in establishing addressability. 



CICS STORAGE AREA 


ABBREVIATION 


SYMBOLIC NAMES 
FOR 
DEFINED STORAGE 


BASE LOCATOR 
OR 
BASE ADDRESS REGISTER 


ASSEMBLER LANGUAGE 

GENERAL PURPOSE 
REGISTER ASSIGNMENT 


Common System Area 


CSA 


DFHCSADS 


CSACBAR 


13 


Common Work_Area 


CWA 


User defined 


CSACBAR 


13 


Transaction Control Area 


TCA 


DFHTCADS 


TCACBAR 


12 


Transaction Work Area 


TWA 


User defined 


TCACBAR 


12 


File Work Area 


FWA 


DFHFWADS 


FWACBAR 


* 


Storage Accounting Area 


SAA 


DFHSAADS 


SAACBAR 


* 


Transaction Input/Output Area 


TI0A 


DFHTIOA 


TIOABAR 


* 


File Input/Output Area 


FIOA 


DFHFIOA 


FIOABAR 


* 


Transient JJata Input Area 


TDIA 


DFHTDIA 


TDIABAR 


* 


Transient Data Output Area 


TDOA 


DFHTDOA 


TDOABAR 


* 


Xemporary Storage Input/Output 
Area 


TSIOA 


DFHTSIOA 


TSIOABAR 


* 


Terminal Control Table 
^Terminal Entry 


TCTTE 


DFHTCTTE 


TCTTEAR 


* 


Application Program Storage 


- 


- 


User defined 


* 


* Any register except 12, 13, and 14 which are utilized by CICS. 



Figure 7. Symbolic names and base addresses of CICS storage areas 



All storage that is acguired by the application program through 
the CICS Storage Management facility is controlled by a technigue that 
chains together all storage associated with a particular transaction. 
(See the section "Storage Accounting Area".) This feature allows CICS 
to release all main storage associated with a transaction, either upon 
ieguest from the user or when the transaction is terminated, normally 
or abnormally. 

The Common System Area (CSA) is the head of the chain, the address 
of which is provided by CICS. The CSA points to the Task Control Area 
(TCA) which in turn points to several of th€ other storage areas. 
Figure 8 illustrates the chaining of CICS storage areas and indicates 
the symbolic base address used to locate each storage area. 
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CICS Logical Relationships 



cics • 



-CSACBAR 



MTCACBAR) 



Storage Control 
Storage Address 



File Control 
Area Address 



Transient Data 
Area Address 



Temporary Storage 
Data Area 



TCASCSA 



TCAFCAA 



TCATDAA 



TCATSDA 




■♦facilities for task C 

■*■ FACILITIES FOR TASK B 



-TCTTEAR 



Terminal Control 
Table Terminal 
Entry 



TCTTEDA 




•FWACBAR 



-\r 



'FIOABAR 



DEHFIOA 



' 16 BYTE FILLER DEF 
i BY USER FOR OS ISAM 



INED \ 
H } 



^ef 



/ 

^ 



EXTWPARTITION_GET 
'^TDIABAR 
^ I DFHTDIA 




j>ut 





Transaction Work Area ' TWA 



This area is defined after the DFHxxxxx. The PL/ I and COBOL 

PROGRAMMER MUST COMPLETE THE BASED STRUCTURE (SYMBOLIC STORAGE 
DEFINITIONS) BY WRITING STATEMENTS WITH A LEVEL NUMBER GREATER 

than 1. The Assembler Language programmer must write DS 

STATEMENTS. 

TCAFCAA.TCATDAA, and TCATSDA are not stored in separate words 
(all three pointers are stored in the same word) 



Figure 8. CICS storage areas are chained together 
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The following sections describe the major CICS storage areas. The 
fields of special significance for the application programmer are 
discussed in detail. * 

CCMMON SYSTEM ABEA (CSA) 

The CSA is an area of static storage that contains areas and data 
reguired for the operation of CICS. It alsc contains a user-defined 
Common Work Area (CWA) that can be used at the discretion of the "user 
for the retention cf temporary data, for the accumulation of statistics, 
for the passing of parameters, etc.; this work area can be accessed 
or altered by any number of tasks. 

Since the work area of the CSA is available to any task while it 
has ccntrcl cf the system, it is not advisable for an application 
program to use this area for retention of data while it is reguesting 
CICS services (for example, File services) . Under these circumstances, 
another transaction might get ccntrcl and possibly destroy the data. 
However, if the user has designed his application programs so they 
are all aware of a common, user-established format within the CSA work 
area, there is no reason why the work area cannot be shared by several 
tasks. An example of this might be a statistics accumulator that is 
updated by more than one transaction. 

Data contained in the CSA that is reguired for the operation of 
CICS includes: 

1. CICS save areas 

2. Addresses of CICS management programs 

3. Control system and user statistics accumulators 

4. Addresses of CICS system control tables 

5. Common system constants 

6. System control parameters 

The fieldjs of the CSA that are of particular significance to the 
application programmer are as follows. 

CSACTOBB: This four-byte binary field contains the time of day in 
hundredths of a second. The time of day is updated periodically during 
task dispatching, its accuracy depending upon the task mix and freguency 
of task switching occurrences. 

CSATODP: This four-byte field of the form HHMMSSt+ contains the time 
of day in packed decimal format to tenths of a second. The time of 
day is updated periodically during task dispatching, its accuracy 
depending upon the task mix and freguency of task switching occurrences. 

CSAWAEA: This field represents the beginning of the Common Work Area 
(CWA) and provides dcubleword storage alignment for it. The entire 
work area is initially set to binary zeros. The size of the work area 
is determined by the user at system generation time. 
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TASK CONTECI ABEA (TCA) 

The TCA is an area of main storage acquired dynamically by CICS 
when the task (transaction) is originated by Task Control. It is used 
to represent the current status of the task and is part of a chain 
of TCA's organized by dispatching priority. During the execution of 
the task, the user has the capability of changing the priority through 
Task Management services; the TCA is then repositioned accordingly. 

The TCA provides the following for its associated task: 

1. Register save areas 

2. Unique fields (parameter areas) for communicating requests to 
CICS 

3. Address of the related Facility Control Area (FCA) 

4. Task storage chain addresses 

When a task is initiated in CICS, the TCA exists until the task 
is terminated. The TCA provides no space for any residual data such 
as statistics; however, the TCA can be extended to include a Transaction 
Work Area (TWA) , the size of which is determined by the user to meet 
the needs of the transaction. (See the section "Transaction Work 
Area".) 

The TCA consists of three logical sections: 

1. CICS system control section 

2. Communication section 

3. Transaction Work Area (optional) 

The CICS system control section contains control addresses and data 

needed by CICS to control the task. Access to this section is limited 

to CICS management programs, CICS service programs, and user-written 
service programs. 

The communication section is used by CICS and by user-written 
application programs for communication between the task and CICS 
management programs and service programs. 

The optional Transaction Work Area is reserved for the exclusive 
use of the task. 

In those cases where a task is initiated from a terminal (nearly 
always the case) , CICS places in the TCA the address of the Terminal 
Control Table terminal entry (TCTTE) associated with the terminal. 
The TCTTE, in turn, contains the address of the Terminal Input/Output 
Area (TIOA) . The TCA also contains the address of either a Single 
Event Control Block or the address of an Event Control Block list. 

The fields of the TCA that are of particular significance to the 
application programmer are as fellows. 

TCAFCAAA: This four-byte field contains the address of the Facility 
Control Area associated with the facility that initiated the 
transaction. This field can contain the address of a Terminal Control 
Table terminal entry, the address of a Destination Control Table entry, 
or the address of an automatic task initiator control area. 

If the user's application program is to communicate with the 
terminal, TCAFCAAA must contain the address of the appropriate Terminal 
Control Table terminal entry (TCTTE). This allows the user's 
application program to reference any data in the TCTTE. 
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TCAPCPI: This eight-byte field contains the identification of the 
reguested program. The program identification is left- justified and 
must meet whatever reguirements there are for a label used in a library 
of the operating system. 

There must be an entry in the Processing Program Table (PPT) 
containing the program identification. This field (TCAPCPI) can be 
filled pricr to issuing a DFHPC TYPE=XCTL, DFHPC TYPE=LINK, DFHPC 
TYPE=LOAD r or DFHPC TYPF=DELETE macro instruction. If the user's 
application program places the program identification in TCAPCPI prior 
to the execution of the macro instruction, the PBOGRAM=name operand 
should be omitted from the macro instruction. 

The program identification can be placed in the TCAPCPI field prior 
to issuing a EFEPC TYPE=LINK macro instruction when an application 
program is testing to determine to which program to link. On the basis 
of the test, the application program should place the program 
identification in the TCAPCPI field and then execute a DFHPC TYPE=LINK 
macro instruction without the PP.OGBAM=nam€ operand. Using this 
technique, the user's application program uses one macro instruction 
tc link tc many different programs. 

TCAPCAC: This four-byte field contains the termination code for the 
DFHPC TYPE=ABFND macro instruction. The termination code must be left- 
justified and must be the user's termination code. The field can be 
filled by the user's program prior to issuing the DFHPC TYPE= ABEND 
macro instruction; in this case, the ABCODE=YES operand must be coded. 

The termination code is placed in the TCAPCAC field prior to the 
execution of the DFHPC TYPE=ABEND macro instruction when the user's 
application program is testing to determine which type of termination 
is desired. 

TCASCSA: This four-tyte field contains the address of the storage 
obtained after the execution of a DFHSC TYPE=GETMAIN macro instruction 
and must also contain the address of the storage to be released prior 
to the execution of a DFHSC TYPE=FREEMAIN macro instruction. The 
application programmer must remember that the first eight bytes at 
this address are always the Storage Accounting Area used by CICS Storage 
Management. Care should be taken never to alter the contents of this 
area. 

The address of the storage obtained from a DFHSC TYPE=GETMAIN macro 
instruction is automatically placed in the TCASCSA field except when 
a conditional GETMAIN request (COND=YES) has been issued and storage 
is not available. In this case, CICS Storage Management places binary 
zeros in this field and returns control to the user. The user's 
application program must specify a symbolic base address for the storage 
area and must move the storage address located at TCASCSA to this 
symbolic base address. The following are examples of the coding 
required. 

121 Assembler lan guag e: 

WOBK DSECT 

USING *,5 



STATE DS CL3 
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CSECT 
BALR 10,0 
USING *, 10 



DFHSC TYPE=GETMAIN 
I 5,TCASCSA 



131 LM COBOL: 

LINKAGE SECTION. 



02 WORKREG PICTURE S9 (8) USAGE IS COMPUTATIONAL, 



01 WOBK, 



02 STATE PICTURE XXX. 



ERCCEDUEE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



DFHSC TYEE=GETMAIN 

MOVE TCASCSA TC WOBKREG. 



lor PL/I: 

DECLARE 1 WCRK BASED (WCRKREG) , 

2 STATE CHAR (3) ; 



DFHSC TYPE=GETMAIN 
WOEKREG=TCASCSA; 

When storage is to be released, the storage address must be placed 
in the TCASCSA field prior to the execution of the DFHSC TYPE=FREEMAIN 
macro instruction. The following are examples of the coding required. 

IQI Assembler lanqjiacje: 

WORK DSECT 

USING *,5 



STATE ES CL5 
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CSECT 
BALR 10,0 
USING *, 10 



ST 5,TCASCSA 

DFHSC TYPE=FRIEMAIN 



121 AJS CCBOL: 

LINKAGE SECTION, 



02 WORKREG PICTURE S9 (8) USAGE IS COMPUTATIONAL. 



01 WORK. 



02 STATE PICTURE XXX, 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



MOVE »OBKREG TO TCASCSA. 
DFHSC TYPE=EREEMAIN 



DECLARE 1 WORK EASED (WCRKREG) , 
2 STATE CHAR (3) ; 



ICASCSA=WORKREG; 
DFHSC TYFE=FREEMAIN 

TCAECNB: This two-byte field contains the length (in bytes) of the 
main storage area to be dumped by Damp Control. This field can be 
filled by the user's application program, prior to execution of the 
DFHDC TYPE=PARTIAL macro instruction, with a hexadecimal representation 
of the number of bytes requested. 

TCASCNB: This two-byte field contains the number of storage bytes 
requested. This field can be filled by the user's application program 
with a hexadecimal representation of the number of bytes requested 
prior to execution of the DFHSC TYPE=GETMAIN macro instruction. If 
the user's application program places a value in this field prior to 
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the execution of a DFHSC TYPE*=GETMAIN macro instruction, the 
NUMBYTE=value operand must be emitted. When the storage is obtained, 
the TCASCNB is overlaid with a portion of the address of the storage ? 
obtained. 

TCASCIB: This one-byte field contains the bit configuration for the 
initialization of main storage. The field can be filled by the user's 
application program with the desired bit configuration prior to the 
execution of a DFHSC TYPE=GETMAIN macro instruction, in which case 
the INITIMG=YES operand must be coded. 

TCAFCDI: This eight-byte field contains the data set identification 
fcr the data set to which a record is to be written or frcm which a 
record is to be retrieved. The user's application program can place 
the data set identification in this field prior to the execution of 
a DFHFC TYPE=GET or a DFHEC TYPE=SETL macro instruction. 

The data set identification must correspond exactly with the user- 
established identification of the reguired data set (as previously 
established in the File Central Table) and must be left- justified when 
the user's application program places the identification in the TCAFCDI 
field. If this field is filled prior to the execution of the DFHFC 
macro instruction, the DATASET=name operand must be omitted. 

TCAFCBI: This four-'byte field contains the address of the user's 
record identification field when caking a reguest for CICS File 
Management services. The user's application program can place the 
address in this field pricr to the execution of a DFHFC TYPE=GET, DFHFC 
TYPE=PUT, EFHFC TYPE=SETL, or DFHFC TYPE=GETNEXT macro instruction. 
The REIDADF,=syrabcl operand is omitted if the TCAFCRI field is filled 
prior to the execution of the macro instruction. 

TCAFCSI: This eight-byte field contains the segment set identification. 
The user's application program can place the segment set identification 
in this field prior to issuing the DFHFC TYPE=GET, DFHFC TYPE=POT, 
EFHFC TYPE=SETL, or DFHFC TYPE=GETNEXT macrc instruction. 

The segment set identification must match the userrsstablished 
identification of the requested segment set (as previously established 
in the File Control Table) and must be left- justified when the user's 
application program places the identification in the TCAFCSI field. 
If this field is filled prior to execution of the DFHFC TYPE=GET or 
DFHFC TYPE=POT macro instruction, the SEGSET=YES operand must be coded 
as part of that macro instruction. 

TCAFCAI: This eight-byte field contains the symbolic identification 
cf the first index data set to be searched in an indirect accessing 
hierarchy. The user's application program can place the desired 
indirect access identification (as previously established in the File 
Ccntrol Table) in the field prior to the execution of a DFHFC TYPE=GET 
macro instruction. When the user's application program places the 
identification in the TCAECAI field, it must be left" justified and 
the INDEX=YES operand must be coded as part of the macro instruction. 

TCAFCAA: This four-byte field contains the address of the File 
Input/Output Area (FIOA) or File Work Area (FWA) . 
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TCAFCTB: This one-byte field contains the type of File. Control 
request/response. Bequest codes are set by issuing the DFHFC macro 
instruction. Besponses are automatically placed in the TCAFCTR field 
by File Management after completion of the event reguested. 

TCATDTB: This one-byte field contains the type of Transient Data 
Control request/response. Bequest codes are set by issuing the DFHTD 
macro instruction. Besponses are automatically placed in the TCATDTB 
by Transient Data Management field after completion of a transient 
data event. 

1CATSTB: This one-byte field contains the Temporary Storage Control 
request/response. Bequest codes are set by issuing the Temporary 
Storage macro instruction DFHTS. Besponses are automatically placed 
in the TCATSTB field by Temporary Storage Management after completion 
of a temporary storage event. 

TCAICTB: This one-byte field contains the Interval Control 
reguest/response. Reguests codes are set by issuing the Interval 
Control macro instruction DFHIC. Responses are automatically placed 
in the TCAICTB field by Time Management after completion of an Interval 
Control service request. 

TRANSACTION WORK AREA (TWA) 

The TWA is an extension of the TCA and is created at the option 
of the user to provide a work area for a given transaction (task) . 

The TWA can be used for the accumulation of data and intermediate 
results during the execution of the transaction. It can also be used 
when the amount of working storage for a transaction is relatively 
static, when data must be passed between user-^written application 
programs, or when data must be accessed by different programs during 
transaction processing. During multiple entries of data for a 
transaction, the application programs might retain the data in the 
TWA. 

Where the TWA is desired for a given transaction, it is the 
responsibility cf the application programmer to define storage for 
the TWA immediately following his symbolic storage definition of the 
TCA. The size of the TWA is specified in the Program Control Table 
entry for each transaction identification. Therefore, the size of 
the TWA can vary by transaction type according to the user's needs. 
For information on establishing the TWA, see the Program Control Table 
in the System Programmer's Befgrgnce Manual. 

JSSJMBLEB LANGUAGE APPLICATION PROGRAMMING 

The Assembler language programmer must define storage for the CICS 
ccntrol areas and any other CICS storage areas required for the 
processing of his program. He accomplishes this by using the Assembler 
language COPY statement to (1) copy the appropriate symbolic storage 
definitions into his program and (2) specify the names of the storage 
areas being defined. All registers are at his disposal, except for 
registers 12, 13, and 14 (which are used by CICS). 
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STATIC STORAGE DEFINITION 

During CICS initialization, the CSA is statically allocated as part 
of the CICS Nucleus. For each terminal with which communication is 
to occur, the Terminal Control Table terminal entry (TCTTE) is included 
in the statically allocated Terminal Control Table (TCT) . The 
application programmer must provide symbolic storage definition for 
the CSA and TCTTE (if needed) by using the COPY statement in his 
program. 

Ccmmon System Area (CSA) 

The statement 

COPY DFHCSADS 

copies the symbolic storage definition for the CSA and assigns register 
13 as the base register. 

If the user has generated a CSA with a work area, he may wish to 
include his own symbolic definitions for that area following the COPY 
DFHCSADS statement. For example: 

COPY DFHCSADS 
BUCKET 1 DS F 
BUCKEI2 DS F 
TEWPNAME DS CI8 

2§^aiBal Control Table Terminal Entry (TCTTE) 

The statement 

COPY DFHTCTTE 

copies the symbolic storage definition for the TCTTE. This symbolic 
definition is necessary when the user desires to obtain the address 
of the terminal I/O area (TCTTEDA) or to reguest a Terminal Control 
service via the DFHTC macro instruction. The user must code an EQD 
statement prior to the COPY statement to set up a base register for 
the TCTTE, eguating the label TCTTEAR to a program register. The 
following is an example of the coding reguired: 

TC1TEAR EQU 5 

COPY DFHTCTTE 



DYNAMIC STORAGE DEFINITION 

During initiation and execution of a transaction (task) , the TCA, 
TIOA,.and other storage areas required by the transaction are 
dynamically allocated by CICS Storage Management, either upon request 
from the application program or upon reguest from a CICS management 
function. The application programmer must provide symbolic storage 
definition for these storage areas by using the COPY statement in his 
program. 

l§sk Control Area (TCA) 
The statement 

COPY DFHTCADS 
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copies the symbolic storage definition for the TCA (excluding the CICS 
control section) and assigns register 12 as the base register. If 
the user's application program uses a Transaction Work Area (TWA) , 
DS statements for that storage area must immediately follow the COPY 
statement. The following is an example of the coding required to 
symbolically define storage for both the TCA and TWA: 





COPY 


DFHTCADS 


NAME 


DS 


CL20 


STRUT 


DS 


CL20 


CITY 


DS 


CL10 


STATE 


DS 


CI 3 



If it is necessary for the Assembler language programmer to obtain 
access to the CICS system control section of the TCA, a copy of the 
symbolic storage definition for the entire TCA may be obtained by using 
the statement 

DFHTCA CICSYST=YES 

in place of the statement COPY DFHTCADS. Addressability to the 
communication section of the TCA and to the Transaction Work Area (TWA) 
is provided automatically by CICS through register 12. Addressability 
to the CICS system control section must be provided by the application 
programmer; for example: 

L WBKREG,TCASYAA 
USING DFHSYTCA,WBKREG 



DROP WRKREG 

3eiSiS§I InfiSi/OuifiUi Area (TIOA) 

The statement 

COPY DFHTIOA 

copies the symbolic storage definition for the CICS control section 
of the TIOA. It is desirable that this storage definition precede 
the user's definition of a terminal input or output message. The user 
must code an EQU statement prior to the COPY statement to set up a 
base register for the TIOA, equating the label TIOAEAR to a program 
register. The following is an example of the coding required: 

TIOABAR EQO 9 

COPY DPHTIOA 

NAME DS CL20 

STREET DS CL20 

DS CL5 



DFHSC TYPE-GETMAIN,NUMBYTE=XX,CLASS=TERMINAL 
L TIOAEAB,TCASCSA 
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lilf 3SJ2Ut/gutput Area (FIOA) 

The statement 

COPY DFHFIOA 

copies the symbolic storage definition for the CICS control section 
of the FIOA. This storage definition should precede the user's defined 
layout of a file input cr output area when reading an unblocked record 
without updating or segmenting, when reading blocked records without 
deblocking, or when checking response codes for the appropriate abnormal 
response. The user must code an EQO statement prior to the COPY 
statement to set up a base register for the FIOA, equating the label 
FIOAEAR to a program register. The FIOA is automatically acquired 
ty File Management whenever a reguest is made by the user to access 
a data base data set. If ISAM data is being retrieved under CICS/OS, 
a 16-byte filler must be defined prior to the user's data definition. 
The following is an example of the coding required: 



OS ISAM FILLER 



Hie Work Area (FWA) 

The statement 

COPY DFHFWADS 

copies the symbolic storage definition for the CICS control section 
of the FWA. This storage definition should precede the user's defined 
layout of a file record area when reading or updating an existing 
blocked or segmented record, when adding a new record to a file, or 
when retrieving records using the browse feature. The user must code 
an EQU statement prior to the COPY statement to set up a base register 
for the FWA, eguating the label FWACBAR tc a program register. The 
following is an example of the coding required: 



FICAEAB 


EQO 


7 




COPY 


DFHFIOA 




DS 


16X 


NAME 


DS 


CL20 


STREET 


DS 


CL5 



FWACEAB 


EQO 


7 




COPY 


DFHFWADS 


NAME 


DS 


CL20 


STREET 


DS 


CL30 


ZIPCODE 


DS 


CL5 



Transient Data Iiiput Area (TDIA) 

The statement 

COPY DFHTEIA 

copies the symbolic storage definition for the CICS control section 
of the intra partition TEIA. It is desirable that this storage 
definition precede the user's defined layout of the message area used 
for a transient data GET. The user must code an EQO statement prior 
to the COPY statement to set up a base register for the TDIA, equating 
the label TDIAEAR to a program register. The following is an example 
of the coding required: 



TDIABAR EQO 


9 


COPY 


DFHTEIA 


NAME DS 


CL20 
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STREET DS CL20 



Transient Data Output Area (TDOA) 

The statement 

COPY DFHTEOA 

copies the symbolic storage definition for the CICS control section 
cf the intrapartition TDOA. For consistent documentation of the user's 
application program, this storage definition should precede the user's 
defined layout of the message area for a transient data PUT. The user 
must code an EQU statement prior to the COPY statement to set up a 
tase register for the TDOA, equating the label TDOABAR to a program 
register. The address of the length field labeled TDOAVRL is given 
to Transient Data Control either through the TDADDR operand or by 
placing it in the TCA at TCATDAA. The following is an example of the 
coding required: 



TDOAEAR 


ECU 


9 




COPY 


DPHTDOA 


TIME 


DS 


cm 


DATE 


DS 


PX3 


INTEBM 


DS 


CL4 



OUTTERM DS C14 



DEHSC TYPE=GETMAIN,CLASS=TRANSDATA,NUMBYTE=XX 
I TDCABAR,TCASCSA 



EFHTD TYPE=PUT,DESTID=POST,TDADDR=TDOAVRL 

Temporary Storage Input^/Output Area (TSIOA) 

The statement 

COPY DEHTSJOA 

copies the symbolic storage definition for the CICS control section 
of the TSIOA. This storage definition should precede the user's defined 
layout of the input/output «rorX areas for temporary storage. The user 
must code an EQU statement prior to the COPY stateient to set up a 
tase register for the TSIOA, equating the label TSIOABAR to a program 
register. The address of the length field labeled TSIOAVRL is given 
to Temporary Storage Control either through the TSEADDR=parameter 
operand of the DFHTS macro instruction or by placing it in the TCA 
at TCATSDA. The following is an example cf the coding required: 
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TSIOAEAR EQD 6 

COPY DFHTSIOA 

PAGENO DS PL2 

TITLE DS CL30 

LINE1 DS CL70 



DFHTS TYPE=GET 

I TSICABAB,TCATSEA 

SH TSIOAEAR, =H'8' 

Storacje Accounting Area (Si A) 

The statement 

COPY DFHSAADS 

copies the symbolic storage definition for the SAA. This storage 
definition should precede the user's defined layout of a unique work 
area he will use within his application program. The user must code 
an EQU statement prior to the COPY statement to set up a base register 
for the SAA, equating the label SAACBAR tc a program register. The 
following is an example of the coding required: 

SAACBAR EQU 9 





COPY 


DFHSAADS 


SYMELA 


ECU 


* 


NAME 


DS 


CL50 


STREET 


DS 


CI15 


SYHBLB 


EQU 


*-SYMELA 



DFHSC TYPE = G 1? TMAIN,INITI«G = CO,NUMBYTE=SYMELB, 
CLASS=05ER 



SAAC5AR,TCASCSA 



EXAMPLE OF CICS ASSEMBLES LANGUAGE APPLICATION EEOGHAM 
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01 


EASEBEG 


ECU 


2 




02 


TCTTEAR 


EQD 


11 




03 


TIOAEAB 


EQU 


10 




on 




COPY 


DFHCSADS 




05 




COPY 


BEHTCADS 




06 


LENGTH 


DS 


H 




07 


MESSAGE 


DS 


CL40 




C8 




COPY 


DFHTCTTE 




09 




COPY 


DFHTIOA 




10 


MESSG 


DS 


CL40 




11 




CSECT 






12 




BALE 


EASEREG,0 




13 




USING 


*,EASEREG 




14 




1 


TCTTEAR,TCA?CAAA 




15 




1 


TICAEAB,TCTTEDA 




16 




MVC 


MESSG, =C«WHAT LANGUAGE AM I CODED IN' 




17 




MVC 


TIOATDL,=H» 27' 




18 




DFHTC 


TYPE= (WRITE, BEAD, WAIT) 




19 




L 


TTOAEAR,TCTTEDA 




20 




MVC 


LENGTH, IIOATDL 




21 




MVC 


MESSAGE, MESSG 




22 




DFHSC 


TYPE=GETMAIN, 


* 


23 






CLASS=TERMINAL, 


* 


24 






INITIMG=40, 


* 


25 






NUMBYTE=40 




26 




L 


TIOABAB,1CASCSA 




27 




ST 


TIOAEAR,TCTTEDA 




28 




MVC 


MESSG, MESSAGE 




29 




MVC 


IIOATDL, LENGTH 




30 




DFHIC 


IYPE=HBITE 




31 




DFHPC 


TYPE=RETURN 




32 




LTORG 






3 3 




END 







Figure 9. Example of CICS Assembler language application program 

A discussion of the significance of each of the lines of Figure 
9 follows. 



STATEMENT NUMBEB 

01 
02-03 

04-05 
06-07 

08-09 





10 


11 


-13 




14 




15 




16 




17 



19 



PJSCBIPTIQN 

Assigns base register for program. 

Assigns base registers for TCTTE and TIOA 

symbolic storage definitions. 

Copies CSA and TCA symbolic storage definitions, 

Defines fields in TWA as save areas to provide 

for quasi-reentrance. 

Copies TCTTE and TIOA symbolic storage 

definitions. 

Defines message area in TIOA. 

Begins program; establishes addressability 

for program. 

Establishes addressability for TCTTE. 

Establishes addressability • for TIOA. 

Moves message to output area of TIOA. 

Moves length of message to data length field 

of TIOA. 

CICS macro instruction that writes message 

to terminal, waits for operator's reply, and 

rsads operator's reply. 

Establishes addressability for new TIOA using 

address in TCTTE. 
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20-2 1 


22-25 


26 


27 


28-29 


30 


31 


32-33 



SJATiMJNT NUMBER DESCRIPTION. 

Saves the message and the length of the 
message in the TWA save areas. 
CICS macro instruction that reguests 40 bytes 
of terminal type storage initialized to blanks. 
Establishes addressability for new TIOA 
(address of newly-acguired storage area is in 
TCASCSA field of the TCA) . 

Places address of new storage area in TCTTE. 
Moves the message and the length of the message 
frcm TWA save areas. 

CICS macro instruction that writes message 
tc terminal. 

CICS macro instruction that returns control 
to CICS and terminates this task. 
Reguired for Assembler language. 

ANS CCBCL APPLICATION PROGRAMMING 

The application programmer who programs in ANS COBOL must define 
storage for the centre! areas and any other storage areas reguired 
for the processing of his prcgranu He accomplishes this (1) by use 
of the COPY statement in- the Linkage Section of the Data Division to 
copy the symbolic storage definitions into his program and specify 
the names of the storage areas being defined and (2) by use of the 
MOVE statement in the Procedure Division to establish addressability 
through the moving of symhelic storage addresses from one location 
tc another. 

The programmer uses normal ANS COBOL code with the exception that 

(1) CICS macro instructions must be used to invoke CICS services and 

(2) the unigue storage areas provided by or acguired through CICS 
should be used for the retention of data. The Working Storage section 
cf an ANS COBOL program should only be used to contain data constants. 
Variable data should be placed in the CICS Transaction Work Area (TWA) 
or in an area of main storage acguired via the DEHSC TYPE=GETMAIN macro 
instruction. 

In the CICS/EOS-ENTRY system, a fresh copy of the program is used 
each time the task is relied back in after a rollout. Therefore, any 
data fields established in the program before rollout occurs must be 
reestablished after subsequent rollin. 

See the secticn "Supervisory and Data Management Services" for a 
listing of ANS COBCL features that may not be used- 

The statement 

01 EFHELLDS COPY DEHELLDS. 

must be the first statement in the Linkage Section of the Data Division, 
This statement copies the symbolic storage definition for the Linkage 
Secticn Base Locator (BLL) which provides the means whereby an ANS 
COBOL program can reguest dynamically acguired CICS storage areas. 
Included in this definiticn is the symbolic base address for the CSA 
and TCA. 

If the ANS CCBCL programmer desires to use CICS storage areas ether 
than the CSA and TCA, immediately following the COPY statement for 
the BLL he must cede statements of the form 

02 name EICTDRE S9(8) DSAGE IS COMPUTATIONAL. 
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where "name" is the symbolic base address used to locate a specific 
storage area. These 02 statements must be coded in the same order as 
the corresponding 01 statements coded subseguently. 

If the user is going to communicate with the system via a terminal, 
he needs a Terminal Input/Output Area (TIOA) and a Terminal Control 
Table terminal entry (TCTTE) . The following is an example of the coding 
required in the Linkage Section of the Data Division: 

01 DFHBLLDS COPY DFHBLLDS. 

02 TCTTEAR PICTURE S9(8) USAGE IS COMPUTATIONAL. 

02 TIOABAR PICTURE S9(8) USAGE IS COMPUTATIONAL. 
01 DFHCSADS COPY DFHCSADS. 
01 DEHTCADS COPY DFHTCADS. 
01 DFHTCTTE COPY DFHTCTTE. 
01 DFHTIOA COPY DFHTIOA. 

If the user wishes to access a series of chained storage areas (areas 

that contain a pointer to the next area in the chain) , he must establish 

addressability to each new storage area in the chain by inserting a 

paragraph name immediately following any MOVE statement that establishes 

addressability but prior to the next sequential statement. For example: 

LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS. 



02 USERPTR PICTURE S9(8) USAGE IS COMPUTATIONAL. 



01 DFHTCADS COPY DFHTCADS. 
02 TWAFIELD PICTURE X(4). 



01 USERAREA. 

02 FIELD PICTURE X (4) . 

02 NEXTAREA PICTURE S9 (8) USAGE IS COMPUTATIONAL. 



PROCEDURE DIVISION. 



MOVE NEXTAREA TO USERPTR. 
ANYNAME. 

MOVE FIELD TO TWAFIELD. 

In this example, storage areas are chained, each of which is mapped 
or defined by USERAREA. The first MOVE instruction establishes 
addressability to the next area in the chain. The second MOVE 
instruction moves data from the newly addressed area, but only because 
the paragraph name precedes the second MOVE instruction; in the absence 
of the paragraph name, data is moved from the previously addressed area 
rather than from the new area. Note that a paragraph name is not needed 
if addressability to an area is obtained via a field in some other area 
(for example, the TCA) . 

If the object of an "OCCURS DEPENDING ON" clause is defined in the 
linkage section, special consideration is required to ensure the correct 
value is used at all times. In the following example, FIELD-COUNTER 
is defined in the linkage section and if the MOVE FIELD-COUNTER TO 
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FIELD-COUNTER statement is missing, unpredictable results will occur 
when referencing DATA. 

LINKAGE SECTION. 

01 DFHFWADS COPY DFHFWADS. 



02 FIELD-COUNTER PIC 9(4) USAGE IS COMPUTATIONAL. 
02 FIELDS PIC X(5) OCCURS 1 to 5 TIMES 

DEPENDING ON FIELD-COUNTER. 
02 DATA PIC X (20) . 



PROCEDURE DIVISION. 



DFHFC TYPE=GET, etc. 

MOVE TCAFCAA TO FWACBAR. 

MOVE FIELD-COUNTER TO FIELD-COUNTER. 

MOVE DATA TO TWA-FIELD. 

The extra MOVE statement to FIELD-COUNTER causes COBOL to 
re-establish the value it uses to compute the current number of 
occurrences of FIELDS and therefore, can correctly determine the 
displacement of DATA. 

An area defined in the Linkage Section that is greater than 4095 
bytes in length reguires special consideration. Reguired are an extra 
02-level statement under DFHBLLDS and an extra statement to establish 



31,1 



addressability. For example, if a FWA (File Work Area) exceeds 4095 
bytes, the following is an example of the code required: 

LINKAGE SECTION 

01 DFHBLLDS COPY DFHBILDS. 



02 FWACBAR PICTURE S9(8) USAGE IS COMPUTATIONAL. 
02 FWABR1 PICTURE S9 (8) USAGE IS COMPUTATIONAL. 



01 DFHFWADS COPY DFHFWADS. 

02 FIELD1 PICTURE X(4000). 
02 FIELD2 PICTURE X(1000). 
02 FIELD3 PICTURE X(400). 



PROCEDURE DIVISION. 



DFHFC TYPE=GET, 



MOVE TCAFCAA TO FWACBAR. 

ADD 4096 FWACBAR GIVING FWABR1 . 

If an application program is to be compiled under CICS/OS using the 
Full ANS COBOL V4 Compiler (5734-CB2) with the optimization (OPT) 
feature, a special compiler control statement must be inserted at 
appropriate places within the program to obtain addressability to a 
particular area of main storage. This control statement has the form: 

SERVICE RELOAD fieldname. 

where "fieldname" is the symbolic name of a specific storage area, and 
where "fieldname" is also defined in an 01-level statement in the 
Linkage Section. The first two statements of the Procedure Division 
must always be 

SERVICE RELOAD DFHBLLDS. 
SERVICE RELOAD DFHCSADS. 

Statements such as: 

MOVE TCAFCAAA TO TCTTEAR. 
SERVICE RELOAD DFHTCTTE. 

or 

SUBTRACT 8 FROM TCASCSA GIVING TSIOABAR. 
SERVICE RELOAD DFHTSIOA. 

might be used to establish addressability for a particular storage 
area. (Note that the SERVICE RELOAD statement must always be used.) 

To establish addressability to the TCA, the following statements 
must be coded: 

MOVE CSACDTA TO TCACBAR. 
SERVICE RELOAD DFHTCA. 
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Note that the RELOAD statement specifies DFHTCA, not DFHTCADS. 

If the application program is to use the Data Language/I (DL/I) 
facilities of CICS/OS as well as the VU ANS COBCL Compiler, the first 
four statements of the Procedure Division must be 

SERVICE RELOAD DFHBLLDS. 
SERVICE RELOAD DFHCSADS. 
MOVE CSAOPFTA TO CSAOPBAR. 
SERVICE BELOAD CSAOPFL. 

STATIC STCBAGE DEFINITION 

During CICS initialization, the Common System Area (CSA) is 
statically allocated as part of the CICS Nucleus. For each terminal 
with which communication is to occur, the Terminal Control Table 
terminal entry (TCTTE) is included in the statically allocated Terminal 
Ccntrol Table (TCT) . The ANS COBCL prograamer must provide symbolic 
storage definition for the CSA and TCTTE (if needed) as fellows. 

Common System Are a (CSA) 

The statement 

01 DFHCSADS COPY DFHCSADS. 

copies the symbolic storage definition for the CSA. Addressability 
for the CSA is included. 

If the user has appended a Common Work Area (CWA) to the CSA, 
immediately following the COPY statement in the Linkage Section he 
must define the record layout of the CWA. The following is an example 
of the coding required: 

01 DFHCSADS COPY DFHCSADS. 
02 CWA PICTURE X (400) . 

03 FIELD1 PICTURE X (4) . 

Terminal Control Table Terminal Entry. (TCTTE) 

The statement 

01 DFHTCTTE COPY DFHTCTTE. 

copies the symbolic storage definition for the TCTTE and must be present 
in all programs requesting communication with a terminal. The user 
must code the statement 

MOVE TCAFCAAA TO TCTTEAE. 

in the appropriate place in the Procedure Division to 
establish addressability for the TCTTE. 

DYNAMIC STORAGE DEFINITION 

During initiation and execution of a transaction (task) , the Task 
Control Area (TCA) , the Terminal Input/Output Area (TIOA) , and other 
storage areas required by the transaction are dynamically allocated 
by CICS. The ANS CGBCL programmer must provide symbolic storage 
definition for these storage areas as fellows. 
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Ijsk Control .Area (TCA) 

The statement 

01 DFHTCABS COPY DFHTCADS. 

copies the symbolic storage definition for the TCA. The user must 
code the statement 

MOVE CSACDTA TO TCACEAR. 

as the first statement in the Procedure Division tc establish 
addressability for the TCA. 

If the user desires to append a Transaction Work Area (TWA) to the 
TCA, immediately following the COPY statement in the Linkage Section 
he must define the record layout of the TWA. The following is an 
example of the coding required: 

01 DFHTCADS COPY DFHTCADS. 
02 TWA PICTURE X(40) . 



^£llS3l IllEUt/0utj3ut Area (TIOA) 

The statement 

01 DFHTICA COPY DFHTIOA. 

copies the symbolic storage definition for the CTCS ccntrcl section 
of the TICA and must be present in all programs that use terminal input 
records or that output records to a terminal. The following is an 
example of the coding required to define the record (s) in the TIOA: 

01 DFHTIOA COPY DFHTIOA. 

C2 TEANSID PICTCRE XXXX. 
02 TICAKSG PICTURE X (20) . 



The user must establish addressability for the TIOA in the Procedure 
Division of his program by coding in the appropriate place either the 
statement 

MOVE TCTTSEA TC TICAEAB. 

or the statement 

HOVE TCASCSA TC TICAEAR. 

The latter statement is used to establish addressability for a new 
TIOA acquired dynamically through use of a DFHSC TYPS^GETMAIN macro 
instruction and should be coded immediately following the last operand 
of that macro instruction. 

Iil§ Illi-Sl/Out^ut ilea (FIOA) 
The statement 

1 DFHFIOA COPY DFHFIOA. 

3U 



copies the symbolic storage definition for the CICS control section 
of the FIOA and must be present in all programs requesting a "read 
without update" for an unblocked, unsegmented data set. If ISAM data 
is being retrieved under CIC5/0S, a 16-byte filler must be defined 
prior to the user's data definition. The following is an example of 
the coding required to define the record (s) in the FIOA: 



1 DFHFIOA COPY DFHFIOA. 

02 FILLER PICTURE X(16). 
02 KEY PICTURE X (6) . 
02 NAME PICTURE X (20) . 
02 FIOABEC PICTURE X(7«4). 



NOTE OS ISAM FILLER. 



The user must code the statement 

HOVE TCAFCAA TO FICAEAR. 

in the appropriate place in the Procedure Division of his program to 
establish addressability for the FIOA. 

file Work Area (FWA) 
The statement 

1 DFHFWAES COPY DFHFWADS. 

copies the symtolic storage definition for the CICS control section 
of the FWA and must be present in all programs performing file activity 
with the exception of a "read without update" from an unblocked, 
unsegmented data set. The following is an example of the coding 
required to define the record (s) in the FWA: 

01 DFHFWAES COPY DFHFWADS. 
02 KEY PICTURE X(6) . 

02 NAME PICTURE X (20) . 
02 FWAREC PICTURE X (24) . 



The user must code the statement 

MOVE TCAFCAA TO FWACEAR. 

in the appropriate place in the Procedure Division of his program to 
establish addressability for the FWA. 

Transient Data Injgut Area (TDIA) 

The statement 

01 EFHTDIA COPY DFHTDIA. 

copies the symbolic storage definition for the CICS control section 
of the intrapartition TDIA and must be present in all programs 
requesting a GET for transient data. The following is an example of 
the coding required to define the record(s) in the TDIA: 
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01 DFETEIA COPY DFHTDIA. 

02 MESSAGE PICTURE X (25) . 

The user must code the statement 

HOVE TCATDAA TO TDIAEAR. 

in the appropriate place in the Procedure Division of his program to 
establish addressability fcr the TEIA. 

Jiausient Data Output Area (TDOA) 

The statement 

1 EFHTEOA COPY DFHTDOA. 

copies the symbolic storage definition for the CICS ccntrcl section 
cf the intrapartition TDOA and shculd be present in all programs 
reguesting a POT to transient data. The following is an example of 
the coding reguired to define the record (s) in the TDOA: 

1 DFHTDOA COPY DFHTDOA. 

02 MESSAGE PICTURE X (20) . 

The user must code the statement 

MOVE TCASCSA TC TDCABAR. 

in the appropriate place in the Procedure Division of his program to 
establish addressability for the TDOA. 

Temporary Storage Input/Output Area (TSTOA) 
The statement 

1 DFHTSICA COPY DFHTSIOA. 

copies the symbolic storage definition for the CICS ccntrcl section 
of the TSIOA and should be present in all programs using temporary 
storage. The following is an example of the coding reguired to define 
the record (s) in the TSIOA: 

01 DFHTSIOA COPY DFHISIOA. 
02 EATA PICTURE X(10). 

To establish addressability for the TSIOA, the user must code in 
the appropriate place in the Procedure Division of his program the 
statements 

MOVE TCA1SEA TO TSI0AEA2. 
SUBTRACT 8 FROM TSICAEAR. 

if the reguest is a GET frcm temporary storage, or the statement 

MOVE TCASCSA TO TSIOABAR. 

if the reguest is a PUT tc temporary storage and the user has just 
dynamically acguired an I/O area. In the case of a PUT, the symbolic 
address of the data is located at TSIOAVRL. 
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Jicracje Accounting Area (SAA) 

The statement 

01 DFHSAADS COPY DFHSAADS. 

copies the symbolic ctorags definition for the SAA. This storage 
definition should precede the definition of user storage acquired 
through the DFHSC TYPS=GEIMAIN,C1ASS=USEB macro instruction. The 
following is an example of the coding required to define the record (s) 
in the SAA: 

01 DFHSAADS COPY DFHSAADS. 
02 NAME PICTURE X(20) . 
02 SAAREC PICTURE X (10) . 



The user must code the statement 

MOVE TCASCSA TO SAACEA3. 

in the appropriate place in the Procedure Division of his program to 
establish addressability for the SAA. 

EXAMPLE OF CICS ANS COBOL APPLICATION PROGRAM 

Figure 10 illustrates an ANS COBOL program written to run under 
CICS. The program issues four CICS macro instructions, asks a question 
of the terminal operator, receives a reply, dynamically acquires some 
storage, and sends the operator's message back to the terminal. (The 
line numbers are not part of the program.) 
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1 


IDENTIFICATION DIVISION. 




02 


PRCGRAM-TD. 




03 




'CBLSPRB'. 




04 


ENVIRONMENT DIVISION. 




05 


DATA DIVISION. 




06 


LINKAGE SECTION. 




11 


01 


BFHELIDS COPY DFflBLLDS, 




C8 




02 TCTTEAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 




09 




02 TICAEAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 




10 


01 


DFHCSADS COPY DFHCSADS. 




11 


01 


DFHTCADS COPY DFHTCADS. 




12 




02 SAVE-LENGTH PICTURE S9 (8) USAGE IS COMPUTATIONAL. 




13 




C2 SAVE-MESSAGE PICTURE X (40) . 




14 


01 


DFHIC1TE COPY DFHTCTTE. 




15 


01 


DFHTIOA COPY DFHTIOA. 




16 




02 TICAMSG PICTURE X (40) . 




17 


PROCEDURE DIVISION. 




18 




MOVE CSACDIA TO TCACBAR. 




19 




MOVE TCAKAAA TC TCTTEAB, 




20 




MOVE TCTTEDA TO TIOABAR. 




1} 




MOVE 'IS THIS A COBOL OR A PL/I PROGRAM' TO TIOAMSC 




22 




MOVE 33 TO TICATDL. 




23 


DF 


HTC TYPE= (WRITE, READ, WAIT) 




24 




MOVE TC1TEDA TO TIOABAR. 




25 




MCVE TICATDL TO SAVE-LENGTH. 




26 




MCVE TICAMSG TO SAVE-MESSAGE. 




27 


DFHSC TYPE=GETMAIN, 


* 


28 




NUMBYTE=40, 


* 


29 




INITIMG=40, 


* 


30 




CLASS=TEE3INAL 




31 




MOVE TCASCSA TO TIOABAR. 




32 




MOVE TICAEAR TO TCTTEDA. 




33 




MOVE SAVE-MESSAGE TO TICAMSG. NOTE MCVE MSG TO I/O AREA. 




34 




MOVE SAVE-LENGTH TC TIOATDL. 




35 


DFHTC TYPEWRITE 




36 


DFHPC IYFE=FETURN 





■Figure 10. Example of CICS ANS COBOL application program 

A discussion of the significance of each of the lines of Figure 
10 fellows. 

STATEMENT NUMBEE DESCRIPTION 

01-05 Required for ANS COBOL. 

06 Start of Linkage Section. 

07 Copies symbolic storage definition for BLL; 
certains addresses of CICS storage areas. 

08-09 Adc addresses for TCTTE and TTOA (required 

for statements 14 and 15). 

Copies symbolic storage definition for CSA. 

Copies symbclic storage definition for TCA. 

Defines save areas in TWA to ensure reentrance 

(SAVE-LENGTH and SAVE-MESSAGE are used to 

save operator's reply). 

Copies symbclic storage definition for TCTTE. 

Copies symbclic storage definition for TIOA. 

Defines message area in TIOA. 

Required for ANS COBOL (start of Procedure 

Division) . 
18-20 Establishes addressability for TCA, TCTTE, and 

TIOA (CICS establishes addressability for BLL 

and CSA) . 
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11 


12-13 


14 


15 


16 


17 



PageofSH20-1047-4 
Revised April 11, 1973 
ByTNLSN20-9012 

21 Moves message to output area of TIOA. 

22 Moves length of message to data length field of 
TIOA. 

23 CICS macro instruction that writes message to 
terminal, waits for operator's reply, and reads 
operator's reply. 

24 Establishes addressability for new TIOA using 
address in TCTTE. 

25 Saves length of message in TWA. 

26 Saves message in TWA. 

27-30 CICS macro instruction that requests 40 bytes 

of terminal storage initialized to blanks 
(terminal storage is chained to Terminal Control 
Table) . 

31 Establishes addressability for new TIOA (address 
of newly-acquired storage area is in TCASCSA 
field of the TCA) . 

32 Places address of new storage area in Terminal 
Control Table. 

33 Moves message to output area (TIOA) . 

34 Moves length of message to output area. 

35 CICS macro instruction that writes message to 
terminal. 

36 CICS macro instruction that returns control to 
CICS. 

PLZI APPLICATION PROGRAMMING 

The PL/I programmer must define storage for the CICS control areas 
and any other CICS storage areas required for the processing of his 
program. He accomplishes this by using a statement of the form 

^INCLUDE (name) ; 

to (1) copy the appropriate symbolic storage definition into his program 
at the place where the 5SINCLUDE statement appears and (2) specify the 
name of the storage area being defined. 

The source code provided by CICS in response to a ^INCLUDE statement 

is in the form of based structures. These structures describe the 

attributes of the storage areas and include pointer variables that 

provide the addresses of the actual locations in storage that the 
structures describe. 

A PL/I program written to run under control of CICS must be written 
with the following considerations and restrictions: 

1. Include the REENTRANT option in the initial PROCEDURE statement 
to satisfy the CICS requirement that code be quasi- reentrant. 
For example: PL1PROG: PROCEDURE OPTIONS (MAIN, REENTRANT) ; 

2. Use CICS macro instructions to request all CICS services. 

3. PL/I object modules from separate compilations cannot be 
link-edited into a single executable program. For subprogram 
linkage, use the DFHPC TYPE=LINK macro instruction. 

See the section "Supervisory and Data Management Services" for a 
listing of PL/I features that may not be used. 

STATIC STORAGE DEFINITION 

During CICS initialization, the Common System Area (CSA) is 
statically allocated as part of the CICS Nucleus. For each terminal 
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with which communication is to occur, the Terminal Control Table 
terminal entry (TCTTE) is included in the statically allocated Terminal 
Control Table (TCT) . The PL/I programmer must provide symbolic storage 
definition for the CSA and TCTTE (if needed) as follows. 
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Common S ys tem Area (CSA) 

The statement 

%INCLUDE (DFHCSADS) ; 

copies the based structure that symbolically defines the CSA. 
Addressability for the CSA is included. 

To define areas in the work area portion of the CSA r the PL/I 
programmer must provide, immediately following the ^INCLUDE (DFHCSADS) 
macro instruction, coding such as the following: 

DECLARE 1 DFHCSAWK BASED (CSACBAR) , 
2 CSAFILL CHAR (512) , 
2 USERLBL1 attributes, 



2 USERLBLn attributes; 

Ter mina l Control Table Terminal. Entry (TCTTE) 

The statement 

ToINCLUDE (DFHTCTTE) ; 

copies the based structure that symbolically defines the TCTTE and must 
be present in all programs reguesting communication with a terminal. 
Addressability for the TCTTE is included. 

DYNAMIC STORAGE DEFINITION 

During initiation and execution of a transaction (task) , the Task 
Control Area (TCA) , the Terminal Input/Output Area (TIOA) , and other 
storage areas reguired by the transaction are dynamically allocated by 
CICS. The PL/I programmer must provide symbolic definition for these 
storage areas as follows. 

Task Control Area (TCA) 

The statement 

%INCLUDE (DFHTCADS) ; 

copies the based structure that symbolically defines the TCA and 
establishes addressability. 

The latter part of the based structure consists of a DECLARE 
statement that is not terminated by a semicolon. The user must complete 
the declaration of the TCA structure by supplying a dummy ending (for 
example, a semicolon) or, if a Transaction Work Area (TWA) is desired, 
by supplying further declaration. The following is an example of the 
coding reguired: 

%INCLUDE (DFHTCADS) ; 
2 TWA CHAR (40) ; 
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2§OiH§i IJ3£*?iZ0.2iElli Area (TIOA) 

The statement 

^INCLUDE (DFHTIOA) ; 

copies the based structure that symbolically defines the CICS control 
section of the TIOA and establishes addressability. This statement 
must be present in all picgrams that use terminal input records or 
that output records to the terminal. The application programmer must 
complete the declaration cf the TIOA structure by supplying a dummy 
ending (for example, a semicolon) or by supplying further declaration 
of the input/output area. The following is an example of the coding 
required: 

^INCLUDE (DFHTIOA) ; 
2 NAME CHAR (20) , 
2 STREET CHAR (20) ; 



DFHSC TYFE=GETMAIN, 

NUMBYTE=XX, 

CLASS=TERMINAL 
TIOABAB=TCASCSA; /* TCASCSA HELD OF TCA CONTAINS ADDRESS 
OF NEWLY-ACQUIRED STOBAGE */ 



Jll§ l££J3i/Pi3i£i3i Are a (FIOA) 

The statement 

%INCLDDE (DFHFIOA) ; 

copies the based structure that symbolically defines the CICS control 
section of the FIOA and must be present in all programs requesting 
a "read without update" for an unblocked, unsegmented data set (file) 
The user must complete declaration of the FIOA. He must establish 
addressability for the FIOA using the statement 

FIOAEAR=TCAFCAA; 

If ISAM is being retrieved under CICS/OS, a 16-byte filler must be 
defined pricr to the user's data definition. The following is an 
example of the coding required: 



%INCLDDE (DFHFIOA) 
2 FILL CHAR (16) 
2 NAME CHAB(2C) 
2 ADDR CHAR (20) 



/*OS ISAM FIILER*/ 



FIOABAR=TCAFCAA; 
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211$ iQTk Are j (FWA) 

The statement 

^INCLUDE (DFHFWADS) ; 

copies the based structure that symbolically defines the CICS control 
section of the FWA. This statement should precede a user-declared 
file record area when reading or updating an existing blocked or 
segmented record, when adding a new record to a data set (file) , or 
when retrieving records using the browse technigue. The user must 
complete declaration of the FWA. He must establish addressability 
for the FWA using the statement 

FWACBAR=TCAFCAA; 

The following is an example of the coding reguired: 

^INCLUDE (CFHFWAES); 
2 NAME CHAR (20) , 
2 ABDR CHAR (20) ; 



FWACBAB=TCUFCAA; 



Trans ient Data Inpjut Ajrea (TDIA) 

The statement 

SINCLUDE (DFHTDIA) ; 

copies the based structure that symbolically defines the CICS control 
section cf the intrapartition TDIA and must be present in all programs 
reguesting a GET for transient data. The user must complete declaration 
of the TDIA. He must establish addressability for the TDIA using the 
statement 

TDIABAR=TCITDAA; 

The following is an example of the coding reguired: 

JINCLODE <DFHTDIA) ; 
2 HSG CHAR (HO) ; 



TDIABAR=TCATEAA; 



Transient Data Output Area (TDOA) 

The statement 

*INCLDtE (DFHTDOA) ; 

copies the based structure that symbolically defines the CICS control 
section of the intrapartition TDOA and should be present in all programs 
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requesting a PUT to transient data (for consistent documentation of 
the' user 1 s programs). The user must complete declaration for the TDOA. 
He must establish addressability for the TDOA using the statement 

TDOABAR=TCASCSA; 

The following is an example of the coding required: 

%INCLODE (DFHTDOA) ; 
2 TIME CHAR (2) , 
2 DATA CHAR (3) , 
2 INTERM CHAR (4) , 
2 OOTTERM CHAR (4) ; 



EFHSC TYPE=GETMAIN, * 

HUMBYTE=XX, * 

CLASS=OSER 

TDOABAR=TCASCSA; 



Temporary Storage In£Ut/Out£ut Area (TSIOA) 

The statement 

?.INCLUDE (DFHTSIOA) ; 

copies the based structure that symbolically defines the CICS control 
section of the TSIOA and should be present in all programs using 
temporary storage. The application programmer must complete declaration 
for the TSIOA. He must establish addressability for the TSIOA using 
ceding such as: 

DCI TSIOAEAA FIXED BIN (30) BASED (TSIOAEAB) ; 
TSICAEAR=ICATSEA; 
TSIOAEAE=ADDR (TSIOABAR) ; 
TSIOAE»A=TSIOAEAA - 8; 

if the request is a GET from temporary storage, or the statement 

TSIOABAR=TCASCSA; 

if the request is a POT tc temporary storage, and the user has just 
dynamically acquired the I/O area. In the case of a POT, the symbolic 
address of the data is located at TSICAVRL. 

Storage Accounting Area (SAA) 

The statement 

^INCLUDE (DFHSAADS) ; 

copies the based structure that symbolically defines the SAA and should 
be present in all programs requesting storage through use of the DFHSC 
TYPE=GETMAIN,CLASS=OSER macro instruction. This statement should 
precede the definition of user storage. The application programmer 
nust complete declaration for the SAA. He must establish addressability 
for the SAA using the statement 

SAACEAR=TCASCSA; 
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The following example illustrates the coding required; 

^INCLUDE (DFHSAADS) ; 
2 MSG CHAR (40) ; 



DFHSC TYPE=GETMAIN, * 

KUMBYTE=60, * 

CLASS=USER 

SAACBAR=TCASCSA; 



EXAMPLE OF CICS TI/I APPLICATION PROGRAM 

Figure 11 illustrates a PL/I program written to run under CICS. 
The program issues four CICS macio instructions, asks a question of 
the terminal operator, receives a reply, dynamically acquires some 
storage, and sends the operator's message back to the terminal. (The 
line numbers are not part of the program.) 



01 


PL1PRCG: PRCCEDOBE OPTIONS 


(MAIN,REEKTRANT) ; 




02 


^INCLUDE (BFHCSAES) ; 












03 


SINCLUEE (BFHTCADS); 












cu 


2 SAVE LENGTH BINARY 


FIXED 


(15), 


r 




05 


2 SAVElHSG CHAR (40) ; 












C6 


^INCLUDE (DFHTCTTE) ; 












C7 


^INCLUDE (DFHTIOA) ; 












C8 


2 TICAMSG CHAR (40) ; 












C9 


TICAMSG=»IS THIS A COBCL 


OB 


A 


PL/I 


PBOGRAM 1 ; 




10 


TIOATDL=33; 












11 


DFHTC TYFE=(WRITE,READ,WAIT) 










12 


TI0AEAE=TC1TEDA; 












13 


SAVE LENGTH=TIOATDL; 












14 


SAVE_M£G=TIOAMSG; 












15 


DFHSC TYPE=GETMAIN, 










* 


16 


NUMBYTE=40, 










♦ 


17 


INITIMG=40, 










* 


18 


CLA£S=TERHINAL 












19 


TTCAEAB=TCASCSA; 












20 


TCTTEDA=TIOAEAR; 












21 


TICAMSG=SAVE_MSG; 












22 


TICATDL=SAVE LENGTH; 












23 


DFHTC TYPE=WRITE 












24 


END; 










. .. 



Ficnire 11. Example of CICS PL/I application program 
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A discussion of the significance of each of the lines of Figure 
1 1 follows. 

STATEMENT NOHBEE DESCRIPTION 

01 Required for PI/I. REENTRANT option 

specified to meet requirement of CICS that 

code be quasi-reentrant. 

Retrieves symbolic storage definition for CSA 

and establishes addressability. 

Retrieves symbolic storage definition for TCA 

and establishes addressability. 

Defines the TWA and terminates the DECLARE 

statement. SAVE_MSG and SAVE_LENGTH are used 

to preserve the operator's reply. 

Retrieves symbolic storage definition for 

TCTTE and establishes addressability. 

Retrieves symbolic storage definition for TIOA 

and establishes addressability. 

Describes I/O area for terminal message and 

terminates the DECLARE statement. 

Places message to be sent to operator in the 

TIOA. 

Places the message length in the terminal data 

length field of the TIOA. 

Writes the message to the terminal, waits for 

the operator's reply, and reads the operator's 

reply. 

Reestablishes addressability for the TIOA 

using address in tie TCTTE. 

Saves the operator's message and message length 

in the TCA. 

CICS macro instruction that requests 40 bytes 

of terminal storage initialized to blanks 

(terminal storage is chained to Terminal Control 

Table) . 

19 Establishes addressability for the new TIOA 
(the address of the newly acquired storage is 
in the TCASCSA field of the TCA). 

20 Places address of new TIOA in Terminal Control 
Table. 

21-22 Moves message and length of message to output 

area (TIOA) . 

23 CICS macro instruction that sends operator's 
message back to the terminal. 

24 Return control to CICS. 





02 




03 


04-05 




06 




07 




08 




09 




10 




11 




12 


13- 


-14 


15- 


-18 
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SERVICE INVOCATION 



CICS provides supervisory and data management services through CICS 
management programs. These services and related management programs 
are as follows: 

• Task services - Task Management 

• Storage services - Storage Management 

• Program services - Prcgram Management 

• Dump services - Dump Management 

• Terminal services - Terminal Management 

• File services - File Management 

• Transient data services - Transient Data Management 

• Temporary storage services - Temporary storage Management 

• Time services - Time Management 

Each of the CICS management programs performs the following basic 
functions: 

1. Analyzes the specific service reguest of application programs 
or other CICS programs. 

2. Performs the requested service by communicating with the 
operating system, as necessary, through macro instructions. 

3. Retains the status of each service reguest until the service 
is provided. 

1. Maintains statistical information that can be used to evalulate 
system performance. 

2 ASK SERVICES 

Task Management provides the capability to process transactions 
(tasks) concurrently. Transactions are scheduled, through Task Control, 
and are processed according to priorities assigned by the user. Control 
of the central processing unit (CPU) is given to the highest priority 
task that is ready to be processed. Control of the CPU is returned 
to the operating system when no further work can be done by CICS or 
by the user-written application programs. 

When a transaction is initiated in CICS, Task Control dynamically 
allocates storage for the Task Control Area (TCA) , attaches the TCA 
to the TCA chain according to priority, obtains the initial program 
identification from the Program Control Table (PCT) , and transfers 
control to Program Control. 

The Task Management macro instruction (DFHKC) is used to reguest 
any of the following services: 

1. Initiate a task. 

2. Change the priority of a task. 

3. Synchronize a task. 

4. Synchronize the use of a resource by a task. 

5. Purge a task on system overload (if the optional stall 
protection feature has been installed) . 
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The following operands can be included in the DFHKC macro 
instruction: 

DFHKC TYPE=ATTACH, * 

FCADDR=symbolic address, * 

TRANSID=name 

DFHKC TYPE=CHAP, * 

PRTY=priority value 

DFHKC TYPE=WAIT, * 

DCI=SINGLE,LIST,DISP, * 

ECADDR=symbolic address 

DFHKC TYPE=ENQ r DEQ, * 

QARGADR=symbolic address, * 

QARGLNG=number 

DFHKC TYPE=PURGE,NOPURGE 

The number of tasks that can be active within the sytem at a given 
time is limited by the availability of main storage and/or by the 
"maximum number of tasks" control. A new task is not initiated by CICS 
unless sufficient main storage is available to process it. Instead, 
the reguest to initiate a task is gueued (stored) until sufficient main 
storage becomes available. 

INITIATE A TASK (ATTACH) 

Task initiation within CICS is invoked by issuing the 

DFHKC TYPE=ATTACH, * 

FCADDR=symbolic address, * 

TRANSID=name 

macro instruction. This macro instruction causes Task Control to obtain 
the controlling area for a task and insert that task within priority 
seguence. This macro instruction is intended to be used by other CICS 
control modules, but is also available for use by the application 
programmer to initiate additional tasks. Any additional tasks initiated 
by the application programmer must terminate themselves through use of 
the Program Control (DFHPC) RETURN macro instruction. 

FCADDR= specifies the symbolic address of a facility control area. 

This is typically the address of the attaching task's TCA or a reserved 

field in the CSA. The purpose is to establish communication between 
the attaching task and the attached task. 

TRANSID= specifies the transaction identification of the attached 
task. 

If the DFHKC TYPE=ATTACH macro instruction is used by the application 
programmer, he has the responsibility to provide the facility control 
area address and transaction identification reguired by CICS to initiate 
a new task. He can accomplish this in either of two ways: (1) by 
including the FCADDR=symbolic address operand and TRANSID=symbolic name 
operand in the DFHKC TYPE=ATTACH macro instruction to statically assign 
to fields in the TCA a facility control area address and a transaction 
identification for the duration of the task, or (2) by coding two 
instructions, pr i or to issuing the DFHKC TYPE=ATTACH macro instruction, 
that provide the capability to dynamically assign to fields in the TCA 
a facility control area address and a transaction identification. (See 
the discussion of the TCA in the section "Storage Definition".) 
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The specified task will not be attached if the transaction 
identification is not in the PCT or the program name is not in the PPT. 
If this situation exists or the attached task ABEND, a message is sent 
to the operator, but the attaching task will not be notified of the 
condition. Therefore the TYPE=ATTACH macro instruction must be used 
with extreme caution by the application programmer. 

For all transactions associated with a terminal, the Facility Control 
Area address is the address of the TCTTE for the terminal. This address 
provides access to control information contained in the Terminal Control 
Table necessary for communication between the program logic and the 
terminal. 

Although it is possible to attach a task directly to a terminal by 
using the ATTACH macro instruction, the application programmer or user 
should consider utilizing one of the following methods: 

• Automatic task initiation through Transient Data Management 

• Automatic task initiation through Time Management (Interval Control 
program) 

• Identification of the transaction ID to be used with the next input 
message from the terminal by means of DFHPC TYPE=RETURN macro 
instruction. 

The following flowchart shows Task A attaching Task B and 
synchronizing the processing steps of both tasks through use of the 
facility control address passed to the newly created task at attach 
time. Note that Task B is a non-terminal oriented task, therefore 
unable to use Terminal Control macros. FCADDR specifies the address 
of Task A's TCA; ECB1 and ECB2 are fields in the TWA for Task A. 
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TASK A 



TASK B 



ATTACH TASK B 
AND POINT 
FCADDR TO 
ECB1 




IFTASK'B' IS 
HIGHER IN 
PRIORITY, IT 
BECOMES 
ACTIVE HERE 



OBTAIN ADDRESS 
OF ECB1 AND 
ECB2 BY USE OF 
ADDRESS NOW 
INTCAFCAAA 



IFTASK'B' 
IS LOWER IN 
PRIORITY IT — 
BECOMES 
ACTIVE HERE 



PROCESSING STEP 1 



POST ECB1 TO MAKE 
TASK 'A' 
DISPATCHABLE 



PROCESSING STEP 2 



TASK 'A' IS AWARE 
THAT TASK 'B' HAS 
COMPLETED 
PROCESSING STEP 1, 



WAIT ON ECB2 
(Note 2) 



TASK'B' IS AWARE 

OF COMPLETION 

OF BOTH STEP 1 
AND STEP 2 



POST 
ECB2 



.TASK'B* GIVES 
UP CONTROL HERE 



.TASK 'B' REGAINS 
CONTROL HERE 



PROCESSING 
STEP 3 



GIVE UP CONTROL 
BY A WAIT OR PC 
RETURN 



Note 1 ; If TASK B is not attached 

(e.g. Trans I.D. not in PCT), 
or if TASK B ABENDS,ECB 1 
may never be posted. 

Note 2; If TASK A ABENDS, ECB2 
may never be posted. 
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Most tasks running un 
and are thus associated 
management programs (for 
Data Control) may or may 
associated with a termin 
as a pointer to addition 
the execution of the tas 
entry in the Destination 
hardware resource (termi 



der CICS are initiated (attached) at a terminal 
with a terminal. Tasks initiated by CICS 
example, automatic task initiation of Transient 
not be associated with a terminal. If not 
al, the Facility Control Area address can serve 
al facility control information required for 
k. For example, it can be the address of an 

Control Table that is associated with a 
nal, data set, etc.). 



The transaction identification is used only for the current ATTACH; 
it is not carried in the TCA for the duration of the task. 

The following example illustrates the coding required to statically 
provide a facility control area address and transaction identification: 



DFHKC TYPE=ATTACH, 

FCADDR=FACCTL, 
TRANSID=TRN1 



INITIATE NEW TASK 
USER'S FCA ADDRESS 
TRANSACTION IDENTIFICATION 



The following examples illustrate the coding required to dynamically 
provide a facility control area address and transaction identification. 



For Assembler language: 



MVC TCAKCTI, = CL4'TRN1 ' 
MVC TCAKCFA,=A(FACCTL) 



TRANSACTION IDENTIFICATION 
USER'S FCA ADDRESS 



DFHKC TYPE=ATTACH 



INITIATE NEW TASK 



For ANS COBOL: 



MOVE 'TRN1' TO TCAKCTI, 
MOVE FACADR TO TCAKCFA, 



NOTE TRANSACTION IDENTIFICATION, 
NOTE USER'S FCA ADDRESS. 



DFHKC TYPE=ATTACH 



INITIATE NEW TASK 



For PL/I: 



TCAKCTI=' TRN1 ' ; 
TCAKCFA=FACADR; 



/♦TRANSACTION IDENTIFICATION*/ 
/♦USER'S FCA ADDRESS*/ 



DFHKC TYPE=ATTACH 



INITIATE NEW TASK 



CHANGE PRIORITY OF A TASK (CHAP) 

The dispatching priority of an existing task can be changed by 
issuing the 

DFHKC TYPE=CHAP r 

PRTY=priority value 

macro instruction. This instruction is used to replace the priority 
value contained in the TCATCDP field of the TCA with a value specified 
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fcy th€ application programmer. This value must be specified in the 
range 0-255, where 255 represents the highest priority. 

The application programmer can change the priority of a task in 
either of two ways: (1) by including the PRTY=priority value operand 
in the DFHKC TYPE=CHAP macro instruction to statically assign to the 
TCATCDP field a new dispatching priority for the duration of the task, 
or (2) by coding a single instruction, prior to issuing the DFHKC 
TYPE=CHAP macro instruction, that provides the capability to dynamically 
assign to the TCATCDP field a new priority value as often as desired 
within a given task. 

A compute bound task can voluntarily relinguish control to all tasks 
of egual or higher priority by issuing a 

DFHKC TYPE=CHAP 

macro instruction. No priority value is specified. 

The following example illustrates the coding reguired to statically 
assign a new task dispatching priority value: 



DFHKC TYFE=CHAP, 
PRTY=255 



CHANGE PRIORITY OF THIS TASK 
NEW PRIORITY VALUE 



The following examples illustrate the coding reguired to dynamically 

assign a new task-dispatching priority value. Note that this value 

can be specified as a binary, decimal, or hexadecimal number, depending 

en the programming language used. 



121 Assembler language: 
MVI TCATCDP, X'FF' 



ASSIGN NEW PRIORITY VALUE 



DFHKC TYPE=CHAP 



CHANGE PRIORITY OF THIS TASK 



IPI AJS CCEOL: 

MOVE 255 TO TCATCDP. 



NOTE ASSIGN NEW PRIORITY VALUE, 



DFHKC TYPE=CHAP 



CHANGE PRIORITY OF THIS TASK 



1°I 11ZI' 

TCATCDP=255; 



/♦ASSIGN NEW PRIORITY VALUE*/ 



DFHKC TYPE=CHAP 



CHANGE PRIORITY OF THIS TASK 



SYNCHRONIZE A TASK (WAIT) 

The application programmer can synchronize a task with the completion 
cf one or mere events related to the same task or to another task by 
issuing the 
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DFfiKC TYPE=W"AIT, * 

ECI=SINGLE,LIST,BISP, * 

ECADDR=symfcclic address 

macro instruction. This nacre instruction provides a method of directly 
relinquishing control to some other task until such time as the event <s) 
teing waited en are completed. It also allows a task to be designated 
as "dispatchable" to voluntarily relinquish control to tasks of a 
tigher dispatching priority. 

The application programmer must specify the circumstances under 
which synchrcnization of a task is- to occur by including the DCI=keyword 
operand (dispatch control indicator) in the DFHKC TYPE=WAIT macro 
instruction. 

Tf the task is to be synchronized with the completion of a single 
event or an event of a list of events, the application programmer must 
specify the symbolic address of either the single event control area 
or the list of event control areas. He can accomplish this in either 
cf two ways: (1) ty including the ECADDR=symbolic address operand in 
the DFHKC TYPE=RAIT macro instruction, or (2) by coding a single 
instruction, iricr to issuing the DFHKC TYPE=WAIT macro instruction, 
that places the event control address in the TCATCEA field of the TCA. 
In either case, the control area (s) referenced must conform to the 
fcrmat and standard posting cenventions associated with the operating 
system (for example, ECB»s in OS/360, CCB's in DOS/360). 

Jelinguish Ccntrcl to a Task of Higher Priority, 

The DFHKC TYPE=WAIT, DCI=DISP macro instruction is used by the 
application programmer tc voluntarily relinquish ccntrcl to a task 
of higher dispatching priority. Control is returned to the waiting 
task if no other task of a higher priority is ready to be processed. 

The following is an example of the coding required to voluntarily 
relinquish contrcl to a task cf higher dispatching priority: 

DFHKC TYPE=«AIT, RELINQUISH CONTROL OF CICS * 

CCI=EISP AND REMAIN DISPATCHABLE 

i?2i§ : When binary synchronous communication lines are part of the 
user's configuration, it is possible for these communication 
lines to tine out if "excessive" CFD time is required by the 
application program. One way to alleviate this condition is 
to have the application program issue a DFHKC TYPE=WAIT,DCI=DISP 
macro instruction to voluntarily relinquish control before the 
line time out can occur. 

Synchronize a Task with a Sinjgle Event 

The DFHKC 1YPE=SAIT,DCI=SINGLE macro instruction is used by the 
applicaticn programmer tc synchronize a task with the completion of 
a single event initiated by the same task or by another task. 

The symbolic address of the appropriate event control area must 
be provided in either of two ways: (1) by including the ECADDR=symbolic 
address operand in the DFHKC TYPE=HAIT,DCI=SINGLE macro instruction, 
or (2) by coding- a single instruction, prior to issuing the DFHKC 
TYPE=WAIT,DCI=SINGLE macro instruction, that places the address of 
the event contrcl area in the TCATCEA field of the TCA. The control 
area referenced must conferm to the format and standard posting 
cenventions associated with the operating system. 
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The following is an example of the coding required to synchronize 
a task with a single event, statically providing the symbolic address 
of the appropriate event control area: 



DFHKC TYPE=WAIT, 
ECI=SINGLE, 
ECADDB=EVENTCTL 



RELINQUISH CONTROL OF CICS 

WAIT ON SINGLE EVENT 

ADDBESS OF EVENT CONTROL AREA 



The following are examples of the coding required to synchronize 
a task with a single event, dynamically providing the symbolic address 
cf the appropriate event control area. 



19* Assembler language; 

ST SINGADDR, TCATCEA 



PLACE SYMECLIC ADDRESS IN TCA 



DFHKC TYFE=WATT, 
DCI=SINGLE 



RELINQUISH CONTROL OF CICS 
WAIT ON SINGLE EVENT 



221 ANS COBOL: 

HOVE SINGABDB TO TCATCEA. NOTE PLACE SYMBOLIC ADDR IN TCA, 



DFHKC TYPE=WAIT, 
DCI=SINGLE 



RELINQUISH CONTROL- OF CICS 
WAIT ON SINGLE EVENT 



I2£ 1I;ZI- 

TCATCEA=SINGADDR, 



/*PLACE SYMECLIC ADDRESS IN TCA*/ 



DFHKC TYPE=WAIT, 
ECI=SINGLE 



RELINQUISH CONTROL OF CICS 
WAIT ON SINGLE EVENT 



Synchronize a Task with a List of Events 

The DFHKC TYPE=WAIT,DCI=LIST macro instruction is used by the 
application programmer to synchronize a task with the completion of 
an element of a list of events. This list consists of a series of 
contiguous four-byte fields, each field containing the symbolic address 
of a single event control area. The last four-byte field of the list 
contains hexadecimal F*s. 

The symbolic address of the appropriate list of event control areas 
must be provided in either of two ways: (1) by including the 
ECADDR=symbclic address operand in the DFHKC TYPE=WAIT,DCI=LIST macro 
instruction, or (2) by coding a single instruction, £rior to issuing 
the DFHKC TYPE=W AIT,DCI=LTST macro instruction, that places the address 
of the list cf event ccntrcl areas in the TCATCEA field of the TCA. 
The control area referenced by each entry in the list must conform 
to the format and standard posting conventions associated with the 
operating system. 

The following is an example of the coding required to synchronize 
a task with a list of events, statically providing the symbolic address 
cf the appropriate list of events: 
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DFHKC TYPE=WAIT, 
DCI=LIST, 
ECADDR=TCPCLIST 



RELINQUISH CONTROL OF CICS 
WATT ON A 1IST OF EVENTS 
ADDRESS 0? LIST OF EVENTS 



The following are examples of the coding required tc synchronize 
a task with a list of events, dynamically providing the symbolic address 
cf the appropriate list of events. 



IQZ. Assembler language: 

ST LISTADDR,TCATCEA 



PLACE SYMECLIC ADDRESS IN TCA 



DFHKC TYPE=WAIT, 
DCI=LIST 



RELINQUISH CONTROL OF CICS 
WATT ON A LIST OF EVENTS 



for ANS COBOL: 

MOVE LISTADDE TO TCATCEA. NO^E PLACE SYMBOLIC ABDE IN TCA. 



DFHKC TYPE=WAIT, 
ECI=LIST 



RELINQUISH CONTROL OF CICS 
WAIT ON A LIST OF EVENTS 



For PL/I: 

TCATCEA=LISTADDR; 



/*PLACE SYMBOLIC ADDRESS IN TCA*/ 



DFHKC TYPE=WAIT, 
ECI=IIST 



RELINQUISH CONTROL CF CICS 
WAIT ON A LIST OF EVENTS 



SINGLE-SERVER RESOURCE SYNCHRONIZATION (ENQ/DEQ) 

In the CICS environment where tasks (transactions) axe processed 
concurrently, it is sometimes desirable tc protect a given resource 
frcm concurrent ms€ by another task. The application programmer can, 
fcy adhering to an installation convention, give sole control of a 
serially reusable resource to a single task until that task is 
completely finished with that resource. He can accomplish this by 
issuing the 

DFHKC TY£E=ENQ, * 

QARGADR=symbclic address, * 

C_AEGLNG=numher 

macro instruction, identifying the resource. This macro instruction, 
when executed, caosps the task to be synchronized with the availability 
of th€ specified resource; control is returned to the task when the 
resource is available. When all programs accessing a resource adhere 
to the convention of "engueing upon" the resource, that resource is 
afforded this "single-server" protection. 

When a single-server resource is being used by a task and other 
tasks concurrently "enqueue" upon the same resource, the first task 
to issue the DFHKC TYEE=ENQ macro instruction receives the resource 
when it becomes available. The other tasks obtain the resource, in 
turn, in the order in which they enqueue upon it. 



s? 



The application programmer can release single-server protection 
from a resource by issuing the 

DFHKC TYPE=DEQ, 

CAEGADR=symbclic address, 
QARGLNG=numb€r 

macro instruction. Task Control automatically "dequeues" all active 
single-server resource protection requests associated with that task 
upon termination of the task. 

When issuing the DFHKC TYPE=ENQ macro instruction, the application 
programmer must identify the single-server resource he is enqueuing 
upon by using either of the following methods: 



1. Specify a symbolic main storage address that represents the 
single-server resource. If this method is used, the application 
programmer must provide the symbolic main storage address by 
including the QARGADR=symbclic address operand in the DFHKC 
TYPE=ENQ macro instruction or by coding instructions, prior 

to issuing the DFHKC TYPE=ENQ macro instruction, that place 
the address in the lcw-crder three bytes of the four-byte TCATCQA 
field of the TCA. He must place binary zeros in the high-order 
byte. 

2. Provide a unique argument, limited to 255 bytes and contained 
at a specified symbolic main storage address, that identifies 
the resource. If this method is used, the application programmer 
must provide the symbolic main storage address of the argument 
along with the length of the argument, by including the 
QARGADE=sy irtclic address and QARGLNG=number operands in the 
DFHKC TYEE=ENQ macro instruction or by coding instructions, 
prior to issuing the DFHKC TYPE=ENQ macro instruction, that 
place the symbolic address in the low-order three bytes of the 
four-byte TCATCQA field of the TCA and the length of the argument 
(in bytes) in the high-order byte. 

The following are examples of the coding required to enqueue upon 
a single-server resource using method 1. 



121 Assembler language: 

DFHKC TYPE=ENQ, 

CAEGAPE=CSAWAEA 



ENQ CN SINGLE-SEBVER RESOURCE 
SPECIFY SYMECLIC ADDRESS 



OR 

LA WORKREG,CSAWABA 
ST WCBKEEG, TCATCQA 



DFHKC TYEE=ENQ 



Eor ANS CCECL: 



01 DFHCSADS COPY EFHCSADS. 

02 CSflWAEA PICTOBE X(50) 



DFHKC TYFE=ENQ, 

CABGADB=CSAWAEA 



ENQ ON SINGLE-SERVER RESOURCE 
SPECIFY SYMEOLIC ADDRESS 
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221 PL/I: 



^INCLUDE BFHCSABS; 

DECLARE 1 DFHEXCSA EASED (CSACBAR) , 

2 FILLER CHAB (512) , 

2 CSABAEA CHAB (50) ; 



DFHKC TYPE=ENQ, 

CAEG2»DB = CSAWAEA 



ENQ ON SINGLE-SEBVER RESOUBCE 
SPECIE! SYMBOLIC ADDRESS 



OR 



TCATCQA=ADER (CSAWABA) ; 



DFHKC TYPE=ENQ 

The following are examples of the coding required to enqueue upon 
a singls-server resource using method 2. 



Jcr Ass ei tier langua g e: 

DFHKC TYFE=ENQ, 

CABG8DE=SOCSECNO, 
CABGLNG=9 



OB 

IA WOBKREG,SOCSECNO 
ST WCEKFEG,TCATCQA 
MVI TCATCQA r 9 



DFHKC TYEE=ENQ 



For ASS CCEOL 



DFHKC TYPE=ENQ, 

CAEGADB=SOCSECNO, 
CARG1NG=9 



lor PJL/I: 



DFHKC TYEE-ENQ, 

CABGADR=SOCSECNO, 
QARGLNG=9 



OR 



XINCLODE DFHTCADS; 

DECLARE 1 DFHEXTCA BASED (TCACBAR> , 

2 FILLER CHAR (20) , 

2 TCATCQAL BIT (8) ; 



TCATCQA=ADDB (SCCSECNO) ; 
TCATCQAL=» 0000 100 1«B; 



5H 



EFHKC TYPE=ENQ 

Substituting "DEQ" for "ENQ" in these examples illustrates the ways 
in which the application programmer can release single-server protection 
from a resource prior to termination of the associated task. 

PURGE A TASK ON SYSTEM OVERLOAD (FURGE/NOPUEGE) 

Certain overload conditions can occur in CICS where all of a given 
system resource (for example, main storage) has been allocated and 
where each task requires still more of that resource. The result is 
a situation where no task is able to continue processing and no new 
task can be initiated; the system stalls. 

If the optional stall protection feature was provided during system 
generation, CICS has the capability to detect certain system overload 
conditions ard tak€ corrective action. Corrective action consists, 
in part, of purging (deleting) the lowest priority task in the system 
that is designated as purgeable. 

A task is initially defined as purgeable or not purgeable by the 
user in the Program Control Table (PCT) entry associated with the 
transaction identification for that task. The application programmer 
can dynamically change the purgeability status of a task by issuing 

the 

DEHKC 1YFE=PURGE 

macro instruction to in-dicate the task is purgeable, or the 

DFHKC TY1=E=N0PURGE 

macro instruction to indicate the task is not purgeable. The designated 
status remains in effect until another change is initiated or until 
the task is terminated. 

The DEHKC TYPE=PURGE and DEHKC TYPE=NOPURGE macro instructions have 
no effect on the execution of a task if the stall protection feature 
is net provided by the user during system generation. 

STORAGE SERVICES 

Storage Management controls all dynamic main storage for CICS and 
for the user-written application programs. Requests to acquire or 
release main storage are communicated to Storage Control via a CICS 
macro instruction. 

CICS management programs issue requests for main storage to provide 
input/output areas, program lead areas, and user-defined work areas 
needed to process a transaction. The user's application program can 
issue requests for main storage to provide intermediate work areas 
and any other main storage not automatically provided by CICS but 
needed to process a transaction. Any main storage acquired by the 
user's application program can be initialized to whatever bit 
configuration the user desires; for example, to binary zeros or EBCDIC 
blanks. 

All main storage associated with a transaction is chained. This 
allows CICS to release all main storage associated with a transaction 
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upon request by the user cr when the transaction is either normally 
cr abnormally terminated. Main storage is accounted for as follows: 

1. Task Ccntrcl Areas (TCA's) are chained off the Common System 
Area (CSS) . 

2. Transaction storage is chained off the Task Control Area (TCA) . 

3. Terminal storage is chained off the TCTTE (the TCTTESC field 
is the origin of the Terminal Input/Output Area (TIOA) chain; 
the TCTTEEA field contains the address of the cu rren t TIOA 
regardless of the position of that TIOA on the chain) . 

4. Program storage is accounted for in the Program Processing Table 

(FFT) . 

5. Suspended tasks are accounted for by the suspending program 
(Task Control, Storage Contrcl, Temporary Storage Control) . 

If there is insufficient main storage to satisfy a storage 
acguisition request, Storage Contrcl causes the processing of that 
task to be delayed by placing it in a "wait" gueue until sufficient 
main storage becomes available. In the meantime, no new tasks are 
initiated by CICS until the "short en storage" condition is alleviated. 
The only exception to this method of allocating main storage occurs 
in the CICS/EOS-ENTRY system where, under certain circumstances, a 
"short on storage" condition causes the transaction to be abnormally 
terminated unless the COND=YES operand has been included in the DFHSC 
r TYPE=GETMAIN macro instruction. (See the section "Purge a Task on 
System Overload" fcr corrective action that can be taken if a "system 
stall" condition occurs.) 

The Storage Management macro instruction (DFHSC) is used to request 
any of the following services: 

1. Acquire and initialize main storage. 

2. Release main storage. 

The following operands can be included in the DFHSC macro 
instruction: 




CETAIN AND INITIALIZE HAIN STORAGE (GETMAIN) 

Requests for main storage are made by issuing the 

DFHSC 1YPE=GETMAIN, * 

INITIMG=number,YES, * 

NDMEYTE=number, * 

COND=YES or (YES , symbolic address) or * 

(NO, symbolic address), * 
CLASS=TERMINAL,USER,TRANSDATA,TEMPSTRG 

macro instruction. This instruction is used by the application 
programmer to obtain main storage of a specified size and class and 
is used, optionally, to initialize that storage to whatever bit 
configuration the application programmer desires. The address of the 
storage area obtained upon execution of this instruction is 
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automatically placed in the TCASCSA field of the TCA by CICS; the 
storage itself is doublewcrd aligned. 

Whenever the application programmer uses the DFHSC TYPE=GETHAIN 
macro instruction, he must do the following: 



1. 
2. 



3. 
4. 



5. 



Specify the class of storage desired using the CLASS=class 

operand in conjunction with the DFHSC TYPE=GETMAIN macro 

instruction. 

Calculate the number of bytes required and either specify that 

amount in the NUMBITE=number operand, or dynamically place it 

in the TCASCNB field before issuing the DFHSC macro instruction. 

Specify a symbolic base address for the storage area. 

Move the storage address located at TCASCSA to the symbolic 

base address. (This address always points to the Storage 

Accounting Area.) 

Copy the symbolic storage definition for the appropriate 

input/output area or Storage Accounting Area .prior to the 

symbolic definition of the user's program storage area. 



The following is an example of the coding required to request a 
new area of main storage: 



DFHSC TYPE=GETMAIN, 
INITIMG=00, 
NUMBYTE=1024, 
CLASS=TEBMINAL 



CBTATN NEW STOBAGE AREA 
INITIALIZE WITH BINAEY ZEBOS 
SIZE OF STOBAGE REQUESTED 
CLASS OF STOBAGE REQUESTED 



The following are examples of the coding required to dynamically 
request a new area of main storage. 



IQI Assembler language: 



MVI TCASCIB,B'0» 
MVC ICASCNB,=H» 1024' 



INITIALIZE WITH BINABY ZEBOS 
SIZE OF STOBAGE BEQUESTED 



DFHSC TYPE=GETMAIN, 
INITIMG=YES r 
CCND=YES, 
CLASS=TEBMINAL 

CLC ICASCSA,=F»0» 

BE NOSTBG 

L TICAEAB, TCASCSA 



CETAIN NEW STORAGE AREA 
INITIALIZE WITH BINARY ZEROS 
RETURN CONTROL IF NO STORAGE 
CLASS OF STORAGE REQUESTED 
CHECK TCASCSA FIELD FOB ZEBOS 
BBANCH TO NOSTRG IF NO STORAGE 
LOAD REGISTER IF STORAGE FOUND 



For ANS COBOL: 



MOVE TO TCACSIB. 
MOVE 1024 10 TCASCNB. 



NOTE INITIALIZE WITH BINABY ZEROS, 
NOTE SIZE OF STOBAGE BEQUESTED. 



DFHSC TYPE=GETMAIN, 

INITIMG=YES, 

CCND=YES, 

CLASS=TEBMINAL 
IF TCASCSA EQUAL GO TC NOSTBG. 
MOVE TCASCSA TO TIOAEAB. 



OBTAIN NEW STOBAGE AREA 
INITIALIZE WITH EINABY ZEROS 
RETURN CONTROL IF NO STORAGE 
CLASS OF STORAGE BEQUESTED 
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For. IIZI: 



TCASCIB-O; 
TCASCNB*1024; 



/♦INITIALIZE WITH BINARY ZEROS*/ 
/♦SIZE OF STORAGE REQUESTED*/ 



DFHSC TYPE=GETMAIN, 
INITIM3=YES, 
COND-(NO,NOSTRG) , 
CLASS-TERMINAL 

TIOAEAR-TCASCSA; 



OBTAIN NEW STOEAGE AREA * 

INITIALIZE WITH BINABY ZEROS * 
RETURN CONTROL IF NO STORAGE * 
CLASS OF STORAGE REQUESTED 
/♦LOAD REGISTER IF STORAGE FOUND*/ 



The DFHSC TYPE=GETMAIN macro instruction can include the following 
operands. 

INITIMG: This operand is used to initialize an acquired storage area 
to the bit configuration specified in hexadecimal, for example, to 
binary zeros (00) or EBCDIC blanks (40) . The application programmer 
can, at his option, place the initialization value in the TCASCIB field 
of the TCA pripr to the execution of the DFHSC TYPE=GETMAIN macro 
instruction; in this case the INITIMG=YES operand must be included 
in the macro instruction* 

KUMBYTE: This operand is used to specify the size of the storage area 
being requested. A value up to 65535 can be specified. The application 
programmer can, at his option, indicate the number of storage bytes 
reguested .prior to execution of the DFHSC TYPE=GETMAIN macro instruction 
by placing this value in the TCASCNB field of the ^CA; in this case 
the KUBBYTE^number operand is omitted. 

U-SjsS! Depending upon the class of storage specified (see the CLASS 

operand below) , CICS Storage Management automatically increments 
the amount of storage requested to allow for the Storage 
Accountinq Area (SAA) and other control information. For 
CLASS=USER and CIASS=TERMINAL (TIOA) storage, the exact number 
of bytes required should be specified. For CLASS=TRANSDATA 
(TDIA and TDOA) and CLA5S=TEMPSTRG (TSIOA) class of storage, 
the amount requested must include four additional bytes to allow 
for a portion of the CICS control information. 

COND: This operand is used by the application programmer to 
conditionally acquire main stcraqe. Control is always returned to 
the user* even if the storage requested is not available. If storage 
is not available, the TCASCSA field of the TCA is filled with binary 
zeros. 

The COND=YES operand causes control to be given to the instruction 
immediately following the DFHSC TYP3=GETMAIN macro instruction. If 
the application programmer uses this operand, he must check the TCASCSA 
field for zeros to determine whether the requested storage area was 
acquired. 

The COND= (YES, symbolic address) operand causes CICS to test whether 
cr not the requested storaqe was acquired. If storage was acquired, 
CICS causes a branch to the location specified in the symbolic address 
parameter; if storaqe was not acquired, control is returned to the 
application program at the instruction immediately following the DFHSC 
TYPE^GETMAIN, COND- (YES, symbolic address) macro instruction. 

The COND= (NO # syffibclic address) operand causes CICS to test whether 
cr not the requested storage was acquired. If storage was not acquired. 
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CICS causes a branch to the location specified in the symbolic address 
parameter; if storage was acquired, control is returned to the 
application program at the instruction immediately following the DFHSC 
TYPE=GETMAIN,COND= (NO, symbolic address) macro instruction. 

CLASS: This operand is used to specify the class of storage being 
requested. If the tasJc itself does not release acquired storage when 
it is sc lcnger needed, the storage is released by CICS upon termination 
of the task. CLASS must be coded with one of the following parameters: 
TERMINAL, DSEB, TRANSDATA, or TEMFSTEG. 

CLASS=TEEMINAL specifies a storage area to be used for terminal 
input/output (TIOA) . This area is chained to the Terminal Control 
Table terminal entry. All requests for storage related to terminal 
input/output must specify this class. 

CLASS=USEE specifies a storage area to be associated with the user's 
application program and used by that program. This area is chained 
to the TCA associated with the task in which the storage is requested. 

CLASS=TBANSDATA specifies a transient data record storage area 
(TEIA, TDOA) . This area is chained to the TCA associated with the 
task in which the storage is requested and is used by Transient Data 
Ccntrcl. 

CLASS=TEMFSTEG specifies a temporary storage input/output area 
(TSIOA) . This area is chained to the TCA associated «ith the task 
in which stcrage is requested and is used by Temporary Storage Control. 

The CLASS=DSEE, CLASS=TEANSDATA, and CLASS=TEMPSTRG specifications 
have essentially the same effect; that is, the number of bytes acquired 
is always eight more than the number specified in the NUMBYTE operand 
(to allow for the storage accounting field) , and the storage is always 
chained off the TCA. The only advantage of using the CLASS=TRANSEATA 
cr CLASS=TEMPSTEG specification instead of the CLASS=OSER specification 
is for the purpose cf code documentation. 

RELEASE MAIN STORAGE (FREEMAIN) 

Previously acquired main storage is released by issuing the 

DFHSC TYPE-FREEMAIN, * 

RELEASE=ALL 

macro instruction. If the task itself does not release acquired 
storage, the- storage is released by CICS upon termination of the task. 

If the application programmer uses the DFHSC TYPE=FREEMAIN macro 
instruction to release a single storage area, he must place the address 
of that area in the TCASCSA field of the TCA £rior to the execution 
of the DFHSC TYPE=FREFMAIN raacrc instruction. If all terminal storage 
acquired by means cf the DFHSC TYPE=GETMAIN,CLASS=TERMINAL macro 
instruction is to be released, the RELEASE=A1L operand can be coded 
in conjunction with the DEHSC TYPE=FREEHAIN macro instruction to achieve 
that result; in this case it is not necessary to place any address 
in the TCA. 

The following is an example of the coding required to release all 
main storage currently allocated to a specific terminal: 

DFHSC TYPE=EREEMAIN, * 

RELEASE=ALL RELEASE AIL TERMINAL STORAGE 
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The following are examples of the coding required to release a 
single main storage area: 

121 Assembler langua ge : 

ST TIOAEAR,TCASCSA PLACE STORAGE AREA ADDRESS IN TCA 

DFHSC TYPE=FREEMAIN RELEASE STORAGE AREA 

For ANS CCEOL : 

MOVE TIOABAR TO TCASCSA. NOTE PLACE STRG AREA ADDR IN TCA. 

DFHSC TTPE=FREEMAIN RELEASE STORAGE AREA 

221 SLZI' 

TCASCSA=TIOABAR; /*PLACE STORAGE AREA ADDRESS IN TCA*/ 

DFHSC TYPE=FREEMAIN RELEASE STORAGE AREA 

FRCGRAM SERVICES 

All program communication within CICS is accomplished by Program 
Management through Progran Control. Requests for program services 
are communicated to Program Control via CICS macro instructions. 

User-written application programs must be coded so that they are 
"serially reusable" between entry and exit points of the program. 
Entry and exit points of a program coincide with the use of CICS macro 
instructions, since an application program temporarily loses control 
after it begins executing only upon execution of a CICS macro 
instruction. A serially reusable portion cf an application program 
is executed by only one transaction at a time, and must initialize 
and/or restore any instructions or data that it alters within itself 
during execution. 

This required quality of application programs written to run under 
CICS is called "quasi-reentrance" , since the programs need not meet 
System/360 or System/370 specifications for true reentrance. Quasi- 
reentrance allows a single copy of a user-written application program 
to be used to process several transactions concurrently, thereby 
reducing the requirement for multiple copies of the same program in 
main storage. 

Transactions can share the use of common worlc areas. However, each 
transaction requires the use of a unique intermediate storage area, 
such as the Transaction Work Area (TWA) , to retain information needed 
upon subsequent return to that transaction. The application programmer 
must provide that intermediate storage area by symbolically defining 
it in his program. 

CICS automatically saves program control information and general 
purpose registers, when applicable, in the Task Control Area (TCA). 
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CICS automatically saves program control information and general 
purpose registers, when applicable, in the Task Control Area (TCA) . 
CICS automatically restores general purpose registers, as necessary, 
to return control to a program. 

The Program Management macro instruction (DFHPC) is used to reguest 
any of the following services: 

1. Link one user-written application program to another, 
anticipating subsequent return to the requesting program. 

2. Transfer control from one user-written application program to 
another anticipating no return to the requesting program. 

3. Load a designated application program or table into main storage 
and return control to the reguesting program. 

4. Return control from one user-written application program to 
another or to CICS. 

5. Release a previously loaded application program from main 
storage. 

6. Abnormally terminate a transaction and its related task. 

The following operands can be included in the DFHPC macro 
instruction: 

DFHPC TYPE=LINK, * 

PROGRAM=name 

DFHPC TYPE=XCTL, * 

PROGRAM=name 

DFHPC TYPE=LOAD, * 

PROGRAM=name, * 

LOADLST=NO 

DFHPC TYPE=RETURN, * 

TRANSTD=transaction code 

DFHPC TYPE=DELETE, * 

PROGRAM=name 

DFHPC TYPE=ABEND, * 

ABCODE=value,YES 

Application programs running under CICS are executed at various 
logical levels. For example, where one user-written application program 
is linked to another, the linked-to program is considered to reside at 
the next lower logical level. Where control is simply transferred from 
one application program to another, the two programs are considered to 
reside at the same logical level. Figure 12 illustrates this difference 
between program linkage and transfer of program control. 

Parameters can be passed from one program to another through 
user-defined storage areas, for example, the Transaction Work Area 
(TWA) , the Terminal Input/Output Area (TIOA) , the Terminal Control 
Table Terminal Entry (TCTTE) , or the File Work Area (FWA) . 
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Figure 12. Application programs are executed at various logical levels 
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PASS PROGRAM CCNTBCL ANTICIPATING SUBSEQUENT RETURN (LINK) 

Program control is passed from a user-written application program 
at one logical level to a user-written application program at the next 
lower logical level in response to the 

DFHPC TYPE=LINK, 

PBCGEAM=name 

macro instruction, When the DFHPC TYPE=BETUBN macro instruction is 
executed in the linked-to program, control is returned to the program 
initiating the linkage at the next seguential (executable) instruction. 

The application programmer must provide the name (identification) 
of the program to which ccntrol is passed. He can do this in either 
cf two ways: (1) by including the PROGRAM=name operand in the DFHPC 
TYPE"=IINK macro instruction, or (2) by coding a single instruction, 
prior to issuing the DFHPC TYPE=IINK macro instruction, that places 
the program name in the TCAPCPI field of the TCA. This same program 
name must also have been placed in the Processing Program Table (PPT) 
prior to execution of CICS. 

The following is an example of the coding reguired to request a 
link to another application program: 

DFHPC TYPE=LINK, * 

EBCGFAM=PB0G1 

The following are examples of the coding required to dynamically 
link to another application program. 

IQI Assembler language: 

MVC TCAPCPI, =CL8»PR0G1» ELACE IINKED-TO PROGRAM NAME IN TCA 



DFHPC TYPE=LINK LINK TO PEOGRAM AT NEXT LOWER LEVEL 

J2I A MS CCECL: 

MOVE »PROG1» TO TCAPCPI. NOTE LINKED-TO PROGRAM NAME TO TCA. 

DFHPC TYPE=LINK LINK TO PROGRAM AT NEXT LOWER LEVEL 

For PL/I: 

TCAPCPI= , PB0G1» ; /*PLACE LINKED-TO PRGM NAME IN TCA*/ 

DFHPC TYPE=LIN-K LINK TO PBOGBAM AT NEXT LOWEB LEVEL 
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TRANSFER EECGEAM CCNTBOL (XCTL) 

Program control is transferred from one user-written application 
program to another at the same logical level in response to the 

DFHPC TYPE=XCTL, ! 

EBCGBAM=name 

macro instruction. The program frcm which control is transferred is 
released. Any return from the transf ered-to program is to a program 
from which there was an exit at the next higher logical level. If 
there is no user-written application program at the next higher logical 
level, control is returned to CICS Program Control. 

The application programmer must provide the name (identification) 
of the program to which control is transferred. He can do this in 
either of two ways: (1) by including the PBOGBAM=name operand in the 
DFHPC TYPE=XCTL macro instruction, or (2) by coding a single 
instruction, .prior to issuing the DFHPC TYPE=XCTL macro instruction, 
that places the program name in the TCAPCPI field of the TCA. This 
same program name must also have been placed in the Processing Program 
Table (PPT) prior to execution of CICS. 

The following is an example of the coding required to request a 
transfer of control to another application program: 

DFHPC TYPE=XCTL, 

EB0GEAM=PB0G2 

The following are examples of the coding required to dynamically 
transfer control to another application program. 

121 Assembler language: 

HVC TCAPCPI, =CL8'ERCG2' ELACE TBANSFEERED-TC PRGM NAME IN TCA 



DFHPC TYPE=XCTL TRANSFER PRQGBAM CCNTBOL 

For AJS CCECL: 

MOVE «PB0G2' TO TCAPCPI. NOTE TR ANSFERBED-TO PRGM NAME TO TCA, 

DFHPC TYPE=XCTL TRANSFER PROGRAM CCNTBOL 

lor PL/I: 

TCAPCPI= , ER0G2 I ; /*PLACE PBOGRJ.M NAME IN TCA*/ 

DFHFC TYPE=XCTL TRANSFER PROGRAM CONTROL 
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LOAD THE SPECIFIED EECGRAN (LCAD) 

Programs or tables are fetched from the library where they reside 
and are loaded intc main storage in response to the 

DFHPC TYPE=LOAD, * 

FRCGEAM=name, * 

LCADLST=NO 

macro instruction, identifying the program to be loaded. This facility 
is used to (1) load a program that will be used repeatedly, thereby 
reducing system overhead through a cne-time load, and (2) load a table 
cr some ncn-executable code tc which control is definitely not to be 
passed. 

The loaded program remains in main storage until the DIHPC 
TYPE=DELETE macro instruction is issued or until the transaction that 
issued the LOAD is terminated, either ncrially cr abnormally (unless 
LOADLST=NO was specified). If the LOADLST=NO operand is used, the 
loaded program is to remain resident until it is deleted by the user. 
CICS returns the address of the leaded program to the user in the 
TCSPCLA field of the TCA. Note that the LOADLST operand is not 
available in the CICS/DOS-ENTRY system. 

The application progranrmer must provide the name (identification) 
of the program to be loaded. He can do this in either of two ways: 
(1) by including the PROGRAM=name operand in the DFHPC TYPE=LOAD macro 
instruction, or (2) by coding a single instruction, ^ricr to issuing 
the DFHPC TYPE=LOAD macro instruction, that places the program name 
in the TCAPCPI field of the TCA. This same prograir name must also 
have been placed in the Processing Program Table (PPT) prior to 
execution of CICS. 

The following is an example of the coding required to load a user- 
written application program: 

DFHPC TYPE=LOAD, * 

PECGEAM=FROG3 

The following are examples of the coding required to dynamically 
load user-written application programs. 

Fo£ Assembler language: 

MVC TCAPCPI, =CL8'EEOG3« ELACE PROGRAM NAME IN TCA 



DFHPC TYPE=LOAD LOAE THE SPECIFIED PROGRAM 

Z°I MS ccjol: 

MOVE «PR0G3« TO TCAPCPI. NOTE PLACE PRGM NAME IN TCA, 
DFHPC IYPE=LOAD LOAE THE SPECIFIED PROGRAM 
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I2£ SLZI' 

TCAPCfI= , rF0G3' ; /*PIACE PROGRAM NAME IN TCA*/ 

DFHPC TYFE=LOAD LOAE THE SPECIFIED PROGRAM 

EETUBN PROGRAM CCHTBCL (RETURN) 

Program control is returned to the next higher logical level in 
response to the 

DFHPC TYFE=BSTURN, * 

TRANSID=transaction code 

macro instruction. The execution of this macro instruction causes 
ccntrcl to be returned to the program at the next higher logical level, 
restoring the registers and releasing save areas for the lower-level 
program. The program to which control is being returned must have 
relinquished control upon execution of a DFHPC TYPE=LINK macro 
instruction and must reside one logical level higher than the program 
returning ccntrcl. Upon normal termination of transaction processing, 
control is returned to CICS Program Control. (Figure 12 shows how 
application programs are executed at various logical levels.) 

The application programmer can, at his option, alter the transaction 
identification for the next program associated with that terminal in 
either of two ways: (1) by including the TRANSID=transaction code 
operand in the EFBPC TYPE=BETURN macro instruction, or (2) by coding 
a single instruction, £ricr to issuing the DFHPC TYPE TYPE=RETURN macro 
instruction, that places the new transaction identification in the 
TCANXTID field of the TCA. 

Note that the TEANSID operand has no effect if a default transaction 
code has been assembled into the Terminal Control Table terminal entry 
(TCTTE) . 

Any higher-level program specifying a TRANSIT overrides the TRANSID 
specification of a lower-level prcgram. TCANXTID is unaltered if 
TRANSID is net coded. 

The DFHPC TYPE=EETURN macro instruction can be used to terminate 
any tasks initiated by the application programmer through use of the 
Task Control (DFHKC) ATTACH macro instruction. 

DELETE A LCADED PROGRAM (IEIETE) 

A program previously leaded through use of the DFHPC TYPE=LOAD, 
IOADLST-NO macro instruction is deleted (released) by the 

DFHPC TYPE=DELETE, * 

ERCGFAM=name 

macro instruction. 

The application programmer must provide the name (identification) 
cf the prcgram to be deleted. He can do this in either of two ways: 
(1) by including the PROGBAM=name operand in the DFHPC TYPE=DELETE 
macro instruction, or (2) by coding a single instruction, prior to 
issuing the DFHPC TYPE=DELETE macro instruction, that places the prcgrai 
rane in the TCAPCPI field of the TCA. 



66 



The following is an example of the coding required to delete a user- 
written application program previously loaded with the LOAD!ST=NO 
specification: 

DFHPC TYPE=DELETE, * 

EROGRAM=ER0G4 

The following are examples of the coding required to dynamically 
delete user-written application programs previously loaded with the 
IOADLST=NO specification. 

1QL Assembler language: 

MVC TCAECPl^CLS^BOGS 1 PLACE PROGRAM NAME IN TCA 



DFHPC TYPE=DELETE DELETE THE SPECIFIED PROGRAM 

191 2JS CCECL: 

MOVE ' PRCGU' TO TCAPCPI. NOTE PLACE PRGM NAME IN TCA. 

DFHPC TYPE=DELETE DELETE THE SPECIFIED PROGRAM 

191 Mill- 

TCAPCFI='PB0G4' ; /*PLACE PROGRAM NAME IN TCA*/ 

DFHPC TYPE=DELETE DELETE THE SPECIFIED PROGRAM 

ABNORMALLY TERMINATE A TRANSACTION (ABEND) 

The application programmer can abnormally terminate a transaction 
and its related task by issuing the 

DFHPC TYPE=ABEND, * 

ABCODE=value,YES 

macro instruction. In the situation where a task is attached by another 
task, only the task that issues the ABEND is terminated. The main 
storage associated with the terminated transaction is released. 

The application programmer can, at his option, request a dump of 
main storage related to the terminated transaction. He can accomplish 
this in either of two ways: (1) by including the ABCODE=value operand 
in the DFHPC TYPE=ABEND macro instruction, or (2) by coding a single 
instruction, prior to issuing the DFHPC TYpE=AEENE, ABCODE=YES macro 
instruction, that places a four-character abnormal termination code 
in the TCAFCAC field of the TCA. This abnormal termination code is 
placed in the output dump by Dump Control when providing the formatted 
storage dump and should be unigue so as to be informative concerning 
the condition that caused the abend. If the ABCODE operand is not 
included in the DFHPC TYPE=ABEND macro instruction, no dump is taken. 
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The following is an example of the coding required to abnormally 
terminate a transaction and its related task and also request a dump 
cf related main storage: 

DFHPC TYPE-ABEND, 
AEC0DE=1234 

The following are examples of the coding required to dynamically 
terminate a transaction and its related task and at the same time 
request a dump cf related main storage. 

IQI Assembler lana.ua.ge: 

HVC TCAPCAC,=CL4' 1234' PLACE TERMINATION CODE IN TCA 



DFHPC TYPE=ABEND, 
AECOEE=YES 



TERMINATE PGRM, TRANS, & TASK 
USE ABCODE ALREADY SPECIFIED 



Jor AKS CCECL: 

MOVE ' 1234' TO TCAPCAC 



NOTE TERMINATION CODE TO TCA. 



DPHPC TYPE=ABEND, 
AECOEE=YES 



TERMINATE PGRM, TRANS, 6 TASK 
USE ABCODE ALREADY SP5CIEIED 



121 IIZI: 

TCAPCAC=» 1234' ; 



/♦PLACE TERMINATION CODE IN TCA*/ 



DFHPC TYPE=ABEND, 
AECOEE=YES 



TERMINATE PGRM, TRANS, S TASK 
USE ABCODE ALREADY SPECIFIED 



DUMP SERVICES 

Dump Management provides the capability, through Dump Control, to 
dump specified areas of main storage onto a sequential data set, either 
tape or disk. This data set contains only the information pertinent 
to the user's transaction or application proqram, and is subsequently 
formatted and printed offline (or while the dump data set is closed) 
using a CICS utility program (DFHDUP) . 

Requests for dump services are communicated to Dump Control via 
CICS macro instructions. Dump Control then executes, at the priority 
of the requesting program, under control of the requesting program's 
TCA, saving and restoring registers from this TCA. After the requested 
dump service has been provided, control is returned to the next 
executable instruction in the requestinq program. 

Dump control operates as a serially reusable program resource with 
only one service request being processed at a time. If additional 
requests for dump services are made while a dump is in progress, the 
tasks associated with those service requests are delayed (suspended) 
and are placed in a "held" status until the dump is completed. 
Remaining dump reguests are serviced on a first in first out (FIFO) 
fcasis. 
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The Dump Management macro instruction (DFHDC) is used to request 
any of the following services: 

1. Dump main storage areas related to a transaction and its 
associated task (or any ether main storage areas) . 

2. Dump all CICS management modules and tables. 

3. Dump transaction-oriented storage areas and CICS management 
modules and tables. 

4. Dump selected main storage areas related to the requesting task. 

The following operands can be included in the DFHDC macro 
instruction: 

DFHDC TYPE=TRANSACTION, * 

DMECODE=value 

DFEDC TYPF=CICS, * 

DMPCCDE=value 

EFHDC TYPE-COMPLETE, * 

EMICODE=value 

DFHDC TYPE=PARTIAL, * 

LIST=TE HMINAI,PROGR AM , SEGMENT ,TRANS ACTIOS, * 

EMECCDE^value 

Note:. To ensure a dump of the TIOA following a Terminal Control write, 
the application programmer must issue a SAVE and WAIT with the 
DFHTC TYPE=WEITE macro instruction that precedes the DFHDC macro 
instruction. Since the Communications Area in the requesting 
task f s TCA is used for Dump Control, the information provided 
in that area prior to the dump will be overlaid. 

DUMP TRANSACTION STORAGE (TRANSACTION) 

The application programmer can request the dump of all main storage 
areas related to a transaction and its associated task by issuing the 

DFHDC TYPE=TSANSACTION, * 

DMEC0DE=valU9 

macro instruction. This dump is normally used during the testing and 
debugging of user-written application programs. CICS automatically 
provides this service in the event the related task is abnormally 
terminated. 

The following storage areas are dumped by CICS in response to the 
TFHDC TYPE=TRANSACTION macro instruction: 

1. Task Control Area (TCA) and, if applicable, the Transaction 
Work Area (TflA) . 

2. Common System Area (CSA) , including the user's porticn of the 
CSA (CWA) . 

3. Task Extension Area (TXA) --applies only to the CICS/DOS-ENTRY 
system. 

4. Trace Table. 

5. Contents of general purpose registers upon entry to Dump Control 
from requesting task. 

6. Either the Terminal Control Table terminal entry (TCTTE) or 
the Destination Control Table entry associated with the 
requesting task. 

7. All transaction storage areas chained off the TCA storage 
accounting field. 
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8. All program storage areas containing user-written application 
program (s) active on behalf of the requesting task. (In the 
CICS/DOS-ENTRY system, only the program in main storage is 
dumped.) 

9. Register save areas (RSA's) indicated by the RSA chain off the 
TCA. 

10. All terminal storage areas (TIOA*s) chained off the Terminal 

Ccrtrol Table terminal entry (TCTTE) for the terminal associated 
with the requesting task (if any) . 

The application programmer can, at his option, provide a four- 
character dump code, which identifies the dump, by including the 
DMICODE=value operand in the DFHDC TYPE=TRANSACTION macro instruction. 
This user-specified code is printed out with the requested dump and 
should be unique so as to be informative concerning the condition that 
caused the dump. 

The following example illustrates the coding required to request 
a dump of transaction storage: 

DFHDC TYPE=TSANSACTION, REQUEST TRANSACTION STORAGE DUMP * 
EMPCODE=D010 USER-SPECIFIED DUMP CODE 

DUMP CICS STORAGE (CICS) 

The application programmer can request a dump of all CICS management 
modules and CICS ccntrol tables by issuing the 

DFHDC TYPE=CICS, * 

DMECODE=value 

macro instruction. This dump is typically used in a testing situation 
where the first dump taken is a CICS dump to ascertain the base of 
the test; subsequent dumps are usually of the TRANSACTION type. 

The application programmer can, at his option, provide a four- 
character dump code, which identifies the dump, by including the 
DMPCODE=value operand in the CFHDC TYPE=CTCS macro instruction. This 
user-supplied code is printed out with the requested dump and should 
be unique so as to be informative concerninq the condition that caused 
the dump. 

The fcllowinq example illustrates the coding required to request 
a dump of CICS management modules and CICS control tables: 

DFHDC TYPE=CICS, REQUEST CICS STORAGE DUMP * 

EMECODE=D020 USER-SPECIFIED DUMP CODE 

DUMP TRANSACTION STORAGE AND CICS STORAGE (COMPLETE) 

The application programmer can request a combination CICS and 
1RANSACTION dump by issuing the 

DFHDC TYPE=COMPLETE, * 

DMECODE=value 

macro instruction. This dump might be appropriate if requested in 
limited numbers durinq execution of a task. Since CICS management 
modules and CICS control tables are primarily static areas, one CICS 
dump and a number of TRANSACTION dumps would be a more efficient testing 
aid than a comparable number of CCHELETE dumps. 
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The application programmer can, at his option, provide a four- 
character dump code, which identifies the dump, by- including the 
EMPCODE=value operand in the EEHDC TYPE=CCMPLETE macro instruction. 
This user-supplied code is printed out with the requested dump and 
should be unique so as to be informative concerning the condition that 
caused the dump. 

The following example illustrates the coding required to request 
a combination CICS and TRANSACTION dump: 

DFHDC TYPE=COHPLETE, BEQUEST COMPLETE STORAGE DUMP * 

DMECODE=D030 USER-SPECIFIED DUMP CODE 

DUMP PABTIAL STORAGE (PARTIAL) 

The application programmer can request a dump of selected main 
storage areas, related to the requesting task, by issuing the 

EEHDC TYPE=PARTIAL, * 

LIST=TERMINAI, PROGRAM, SEGMENT, TRANS ACTION, * 

EMECCDE=value 

macro instruction. This type of dump can be used during the testing 
and debugging of user-written application programs. It includes only 
those types of storage areas specified. 

The application programmer must indicate what types of storage areas 
he wants dumped. He accomplishes this by specifying in the LIST operand 
of the EFHEC TYFE=PABTIAL macro instruction one or more of the following 
parameters: TERMINAL, PBCGRAM, TRANSACTION, SEGMENT. 

The application programmer can, at his option, provide a four- 
character dump code identifying the dump ty including the DMPCODE=value 
operand in the EFHEC TYPE=PARTIAL macro instruction. This user- 
specified cede is printed out with the requested dump and should be 
unique so as to be informative concerning the condition that caused 
the dump. If more than one parameter is included in the LIST operand, 
a single dump cede can be used to identify the entire dump. 

A discussion of the parameters that can be included in the LIST 
operand of the DFHEC TYFE=PJ»RTIAL macro instruction follows. 

TERMINAL: This keyword parameter is used to include in the PARTIAL 
dump all storage areas associated with the terminal. These storage 
areas are as follows: 

1. Task Ccntrcl Area (TCA) and, if applicable, the Transaction 
Work Area (TWA) . 

2. Common System Area (CSA) , including the user's portion of the 
CSA (CWA) . 

3. Task Extension Area (TXA) — applies only to the CICS/DOS-ENTBY 
system. 

4. Trace Table. 

5. All terminal storage areas (TIOA's) chained off the Terminal 
Ccntrcl Table terminal entry (TCTTE) for the terminal associated 
with the requesting task. 

6. Contents of general purpose registers upon entry to Dump Control 
frcm the requesting task. 

7. Either the Terminal Control Table terminal entry (TCTTE) or 
the Destination Control Table entry associated with the 
reguesting task. 
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The following example illustrates the coding required to request 
a PARTIAL storage dump including all terminal storage areas: 

EFHDC TYPE=?ARTIAL, BEQUEST PARTIAL STOBAGE DUMP * 

LIST=TERMINAI, AESAS ASSOCIATED WITH TERMINAL * 

BM¥CCBE=DTML USER-SPECIFIED DUMP CODE 

PROGRAM: This parameter is used to include in the PARTIAL dump all 
Frogram storage areas associated with this task. These storage areas 
are: 

1- Task Ccntrcl Area (TCA) and, if applicable, the Transaction 
Work Area (TWA) . 

2. Common System Area (CSA), including the user's portion of the 
CSA (CWA) . 

3. Task Extension Area (TXA) --applies only to the CICS/DOS-ENTRY 
system. 

U. Trace Table. 

5. All program storage areas containing user-written application 
program (s) active en behalf of the requesting task. 

6. Register save areas (RSA's) indicated by the RSA chain off the 
TCA. 

7. Contents of general purpose registers upon entry to Dump control 
frcm the requesting task. 

8. Either the Terminal Control Table terminal entry (TCTTE) or 
the Destination Control Table entry associated with the 
reguesting task. 

The following example illustrates the coding required to request 
a PARTIAL storage dump including all program storage areas associated 
with this task: 

DFHDC TYPE=PARTIAL, REQUEST PARTIAL STORAGE LUMP * 
LIST=FEOGRAH # PROGRAM STORAGE AREAS * 

EHPCOEE=DFGM USER-SPECIEIED DUMP CODE 

TRANSACTION: This parameter is used to include in the PARTIAL dump 
all transaction stcrage areas associated with this task, typically 
in conbination with other types of storage areas such as TERMINAL or 
FFOGRAM. 

The following storage areas are dumped by CICS in response to the 
IFHDC TYPE=PARTIAL,LIST=THANSACTION macro instruction: 

1. Task Ccntrcl Area (TCA) and, if applicable, tha Transaction 
work Area (TWA) . 

2. Coirmon System Area (CSA), except for the user's portion of the 
CSA (CWA) . 

3. Task Extension Area (TXA) — applies only to the CICS/DOS-ENTRY 
system. 

4. Trace Table. 

5. Contents of general purpose registers upon entry to Dump Control 
frcm the requesting task. 

6. Either the Terminal Control Table terminal entry (TCTTE) or 
the Destination Control Table entry associated with the 
requesting task. 

7. All transaction storage areas chained off the TCA storage 
accounting field. 

The following example illustrates the coding required to request 
a PARTIAL storage dump that includes, along with all program storage 
areas, all transaction storage areas associated with this task: 
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DFHDC TYPE=PARTIAL, 

LIST = (TRANSACTION, 
EROGBAM) , 
EMECODE=DT&P 



BEQUEST PARTIAL STORAGE DUMP * 

AREAS ASSOCIATED WITH TRANSACTION * 

EROGRAM STORAGE AREAS * 
USER-SPECIFIED DUMP 'CODE 



SEGMENT: This parameter is used to include in the PARTIAL dump any 
area of main storage specified. For example, use cf this parameter 
enables the application programmer to dump the area of main storage 
used for communication between the Terminal Abnormal Condition program 
(DFHTACP) and the Terminal Error program (DEHTEP) . In addition, the 
following storage areas are provided: 

1. Task Control Area (TCA) and, if applicable, the Transaction 
Work Area (TWA) . 

2. Common System Area (CSA) , including the user's portion of the 
CSA (CWA) . 

3. Task Extension Area (TXA) — applies only to the CICS/DOS-ENTRY 
system. 

4. Trace Table. 

5. Contents of general purpose registers upon entry to Dump Control 
from the reguesting task. 

6. Either the Terminal Control Table terminal entry (TCTTE) or 
the Destination Control Table entry associated with the 
requesting task. 

The application programmer must code two instructions, prior to 
issuing the DEHEC TYPE=PARTIAL,LIST=SEGMENT macro instruction, that 
place the address of the main storage area to be dumped into the TCADCSA 
field of the TCA and the length of the area to be dumped into the 
TCADCNB field of the TCA. 

The following are examples of the coding required to include in 
the PARTIAL dump any area of main storage. 



l2£ h§s§®]£l§I lang uage : 

ST R5, TCADCSA 

MVC TCADCNB, =HM6384' 



PLACE STOEAGE ADDRESS IN TCA 
PLACE LENGTH OF AREA IN TCA 



DFHDC TYPE=PARTIAL, 
LIST=SEGMENT, 
DMFCODE=DMSA 



BEQUEST PARTIAL STORAGE DUMP * 
DUMP AREA PREVIOUSLY SPECIFIED * 
USER-SPECIFIED DUMP CODE 



For ANS COEOL: 



MOVE R5 TO TCADCSA. 
MOVE 16384 TO TCADCNB. 



NOTE PLACE STBG ADDRESS IN TCA, 
NOTE PLACE LENGTH OF AREA IN TCA, 



DFHDC TYPE=PARTIAL, 
LIST- SEGMENT, 
DMPCODE=DMSA 



BEQUEST PARTIAL STORAGE DUMP * 
DUMP AREA PREVIOUSLY SPECIFIED * 
USER-SPECIFIED DUMP CODE 



lor PL/I: 



TCArcSA=R5; 
TCADCNB=16384; 



/♦PLACE STORAGE ADDRESS IN TCA*/ 
/♦PLACE LENGTH OF AREA IN TCA*/ 
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DFHDC TYPE=PARTTAL, BEQUEST PARTIAL STORAGE DUMP * 
LIST=SEGMENT, DUMP AREA PREVIOUSLY SPECIFIED * 
EMPCODE=DKSA USER-SPECIFIED DUMP CODE 



TERMINAL SERVICES 

Terminal Management provides communication between the terminals 
and user-written application programs through Terminal Control. 
Terminal Control is responsible for the polling and addressing of 
terminals, code translation, transaction initiation, task and line 
synchronization, and the line control necessary to read from or write 
to a terminal. The user-written application program is thus relieved, 
as much as possible, from having to control the physical terminal 
environment. 

Reguests for terminal services are communicated to Terminal Control 
via CICS macro instructions. However, when such reguests are issued 
in an application program, Terminal Control is not entered directly. 
Instead, indicators are set in the Task Control Area (TCA) and in the 
Terminal Control Table (TCT) which allow Terminal Control to provide 
the reguested service (s) . Individual application programs thus 
interface with a terminal logically and symbolically. 

Terminal Control operates as a system-provided task, contending 
with user-provided tasks in the system. It executes under control 
of its own TCA and is the highest-priority task in CICS. Terminal 
Control is always the first task to be dispatched by CICS; it scans 
the TCT and provides whatever services are reguested. 

The Basic Telecommunications Access Method (BTAH) is used by CICS 
for most terminal management. The Telecommunications Access Method 
(TCAM) can optionally be specified. However, the Seguential Access 
Method (SAM) is used where key-driven terminals are to be simulated 
by seguential devices such as a card reader. The Graphics Access 
Method (GAM) is used only in the CICS/OS-STANDARD system to support 
local 2260 terminals. 

J?2i.§! Tne multipunched character 0*2-8 must be used in each physical 
input record immediately following the last data character to 
simulate the "end of block" (EOB) . For seguential devices, 
the last entry in the input stream must be *CSSF GOODNIGHT" 
to provide a logical close. For MFT/MVT users of the CICS/OS- 
STANEARD system having blocked SYSIN or SYSODT, overriding DD 
cards must be provided for those CICS data sets being used to 
simulate terminals. 

The Terminal Management macro instruction (DFHTC) is used to reguest 
any of the following services: 

1. Write olata to a terminal. 

2. Read data from a terminal. 

3. Synchronize terminal input/output for a transaction. 
1. Converse with a terminal. 

5. Transmit a page of data to a terminal. 

6. Transmit to the common buffer of a 2980 General Banking Terminal 
System. 

7. Test for the presence of a passbook in the 2980 General Banking 
Terminal System Models 1 and 4. 

The following operands can be included in the DFHTC macro 
instruction: 
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DFHTC TYPE= (WRITE, WRITEL, READ, READ!, WAIT, EBASE, SAVE, OIU, * 

DISCONNECT, RESET, READB, COPY, EBASEAUP,CBUFF, * 

PASSBK,lBANSPABENT,PSEUDOEIN,NOTBANSLATE) , * 

LINEADB=number,YES, * 

CTLCHAB=hexadecimal number, YES, * 

DEST=symbolic name, YES, * 
EOF=symbclic address 

BFETC TYPE= (GET, PUT, ERASE, SAVE, TRANSPARENT, PS>EUDOBIN) , * 

LINEADR=number,YES, * 

CTLCHAR=hexadecimal cumber, YES, * 

DEST=symbolic name, YES, * 
EOF=symbolic address 

DFHTC TYPE= (PAGE, SAVE) , * 

LINEADR=number,YES, * 

CTLCHAR=hexadecimal number, YES, * 
DEST=symbolic name, YES 

DFHTC TYPE= (CONVERSE, ERASE, SAVE) , * 

LINEADR=number,YES, * 

CTLCHAB=hexadecimal number, YES, * 
DEST=symbolic name, YES 

DFHTC EOF=symbclic address 

WRITE, WRITEL, BEAD, BEADL, WAIT, ERASE, SAVE, OIU, DISCONNECT, 
RESET, BEADB, COPY, EBASEAUP, TRANSPARENT, PSEUDUBIN, and NOTBANSLATE 
are optional keyword parameters and may be specified in any combination 
cr in any order, as applicable. Each parameter, independent of its 
position, affects the setting of an associated bit in the Terminal 
Control Table Terninal Entry (TCTTE) so the order in which each 
parameter is specified has no effect on the meaning. For example, 
(WRITE, READ, SAVE) is equivalent to (WRITE, SAVE, BEAD) and (SAVE, 
WRITE, BEAD) etc. CBUFF and PASSEK are stand-alone parameters that 
have implied writes and waits. GET, PUT, PAGE, and CONVERSE are used 
for coding convenience; they are combinations of the other parameters 
as fellows: 

1. GET - same as READ, WAIT 

2. PUT - same as WRITE, WAIT 

3. PAGE - same as ERASE, WEITE, BEAD, WAIT 

4. CONVEBSE - same as WEITE, BEAD, WAIT 

Note: When coding an application program in ANS COBOL, a WAIT mjust 

be included with every READ, BEADL, WBITE, WRITEL, BEADB, COPY, 
and ERASEAUP, except in the case of the final WRITE of the 
pregtam. 

The DISCONNECT parameter is used by the application programmer to 
break the line connection between the terminal and the computer; it 
applies only to switched lines. If the terminal is a buffered device, 
the data in the buffer (s) is lost. 

The RESET parameter is used by the application programmer to 
relinquish use of the ccmmunicaticn line; it applies enly to binary 
synchronous terminals- When RESET is used, the next BTAM type of 
operation will be a read or write initial. 

The READE parameter is applicable only to the 3270 Information 
Display System and is used by the application programmer to read the 
entire contents of the 3270 buffer. Data transmission starts at buffer 
location and continues until the contents of the entire buffer have 
teen read. All character and attribute sequences (including nulls) 
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appear in the input data stream in the same order as they occur in 
the 3270 buffer. 

Note: Because of relatively long transmission times required to 

transmit the entire contents of a remote 3270 Information Display 
Station buffer, it is recommended that the READB parameter be 
used mainly for test and diagnostic purposes and that the COPY 
parameter be used, where possible, in all other cases. Excessive 
use of the READB parameter may cause degradation of performance 
on the line. 

The COPY parameter is applicable only to the remote 3270 Information 
Display System and is used by the application programmer to copy the 
format and data contained in the buffer of another terminal attached 
to the same 3271 Control Unit, The physical address of the device 
to be copied is provided as the first and only character in the output 
data area (TIOADBA) ; TIOATDI must be set to 1. The Copy Control 
Character (CCC) , which controls and defines the copy function to be 
performed, is supplied through the CTLCHAR operand. The COPY parameter 
cannot be included with a WRITE, ERASE, or EBASEADP parameter in the 
same macro instruction. 

The ERASEAUP parameter is applicable only to the 3270 Information 
Display System and is used by the application programmer to issue an 
"erase all unprotected" command. The following functions are performed 
in response to this command: 

1. All unprotected fields are cleared to nulls (X'OO 1 ). 

2. The modified data tags in each unprotected field are reset to 
zero. 

3. The cursor is positioned to the first unprotected field. 

4. The keyboard is restored. 

The ERASEADP parameter cannot be included with « WRITE, ERASE, or 
COPY parameter in the same macro instruction. Note that no data stream 
is supplied for this command. 

The CBUFF parameter is applicable only to the 2980 General Banking 
Terminal System and is used by the application programmer to place 
a message in the common buffer of the 2972 Terminal Control Unit. 
The 2972 associated with the current Terminal Control Table terminal 
entry (TCTTE) receives the output message. 

Note: The output message is translated according to the 2980 model 
being described by the current TCTTE. If more than one model 
of the 2980 is attached to a 2972 Terminal Onit, the contents 
of the common buffer are intelligible only for the 2980 model 
for which the message was translated. Since shift characters 
are added to the message by CICS during translation, the message 
length is dependent upon the contents of the message. The 
maximum message length is 23 characters, including shift 
characters. 

The PASSBK parameter is applicable only to the 298t) General Banking 
Terminal System and is used by the application programmer to cause 
output to be printed on a banking passbook. If a passbook is not 
present, printing does net occur and an error message is sent to the 
terninal operator. 

The TRANSPARENT parameter is applicable only to the System/7 and 
is used by the applicaticr programmer to indicate that the data is 
not to be translated on either a READ or WRITE. For further information 
concerning System/7 programming considerations, see the section 
"Application Programming Considerations". 
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The PSEODOBIN parameter is applicable only to the System/7 and is 
used by the application programmer to indicate that the data is to 
he translated en both a READ and WRITE. Translation is from System/7 
pseudo-binary representation to hexadecimal representation on a READ, 
and from hexadecimal representation to System/7 pseudo-binary 
representation on a WRITE. For further information concerning System/7 
programming considerations, see the section "Application Programming 
Considerations" . 

The NOTRANSLATE operand is applicable only to the 3735 Programmable 
Euffered Terminal, and is used by the application programmer to prevent 
translation of FDP records which are to be transmitted to a 3735 using 
ASCII transmission code. For further information, see the section 
"Application Programming Considerations". 

The LIUEADB operand is used to specify that writing is to begin 
on a specific line of a 2260 or 2265 screen. It is the responsibility 
of the application programmer to provide the hexadecimal equivalent 
of a line number in the range 1-12 (FO-FB) for the 2260 or 1-15 (F0- 
FE) for the 2265. He can accomplish this in either of two ways: (1) 
by including the IINEADB=cumber operand in the DFHTC macro instruction, 
or (2) by coding a single instruction, prio r to issuing the DFHTC macro 
instruction, that places the line number in the TIOALAC field of the 
current TIOA. If the latter method is used, the LINEADR=YES operand 
must be included in the DFHTC macro instruction. For further 
information concerning the use of this operand, see the section 
"Application Programming Considerations". 

The CTLCHAR operand is applicable only to the 3270 Information 
Display system. If a DEHTC TYPE=WRITE macro instruction is issued, 
this operand is used to provide the hexadecimal representation of the 
Write Control Character (WCC) which controls the reguested write 
operation. If a DFHTC TYPE=COPY macro instruction is issued, this 
operand is used to provide the hexadecimal representation of the Copy 
Control Character (CCC) which controls and defines the copy function 
to be performed. 

If CTLCHAR=YES is specified, the appropriate bit configuration must 
have been previously moved to the TIOACLCR field of the TIOA. If only 
the functions defined by the WCC are to be performed (that is, no data 
stream is to be supplied) , the TIOATDL field of the TIOA must have 
been previously set to zero. 

If the CTLCHAR operand is omitted, the following functions are 
assumed for the WCC and CCC. 

WCC: Reset all modified data tags to zero. 
Restore the keyboard. 

CCC: Copy the contents of the entire buffer (including nulls) . 

The DEST operand is applicable only to TCAM. If a DFHTC TYPE=WRITE 
macro instruction is issued, the DEST operand can be used to send a 
message to a destination ether than the source terminal. Typically 
this operand could be used to route messages to: 

1. The master terminal (if TCAM is used) 

2. A list of terminals if a TIIST macro was coded in the TCAM MCF. 

The DFHTC IYPE=WBITE,DEST=symbolic name macro instruction determines 
the destination of the message by CICS placing the symbolic name in 
the four-byte TCTTE field labeled TCTTEDES for processing by the 
Terminal Control program. The DFHTC TYPE=WRITE,DEST=YES macro 
instruction allows the user to dynamically select a destination by 
placing the destination in the four^byte TCTTE field labeled TCTTEDES 
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prior to issuing the WRITE macro instruction. If DEST is not specified, 
the default action is to love the source terminal ID located in the 
TCTTETI field to the output message to provide a TCAM destination name, 
sending the message back to the source terminal. 

The EOF=symbolic address operand is used to specify a routine in 
the application program which is to receive control when an end-of- 
file condition has been received en batch input from a 3735. The 
special initialization macro instruction, DFHTC EOF=symbolic address, 
has been provided to test for the ead-of-file condition upon the initial 
connection to a 3735. This macro instruction must be included in the 
initialization section of the •3735* transaction before subsequent 
EFHTC macro instructions are issued. 

Note: When the EOF condition occurs, the IIOATDL field of the TIOA 
passed tc the application program contains binary zeros to 
indicate that the TIOA contains no valid data. 

Applicable only to terminals attached to a 2848 Display Control 
Model 21 or 22, the READL and WRITE! parameters are used by the 
application programmer to control the locking and unlocking of the 
terminal keyboard after a read or write event. READL is applicable 
only to CICS/OS but may be used in CICS/DOS application programs if 
upward compatibility with CICS/OS is a consideration; it causes the 
keyboard to remain locked at the completion of data transfer. WRITEL 
causes the keyboard to regain locked if previously locked, or remain 
unlocked if previously unlocked. (WRITE always leaves the keyboard 
unlocked.) 

If DFHTC macro instructions are issued in the following sequence, 
the keyboard is locked or unlocked as indicated: 





QIQS/DOS 


CICS/OS 


READ 


L 


u 


WRITEL 


L 





READL 


L 


L 


READL 


L 


L 


WRITEL 


L 


L 


WRITEL 


L 


L 


WRITE 





a 


WRITEL 


U 





WRITEL 








READ 


L 


a 


WRITE 


D 


u 


READL 


L 


L 


READ 


L 





WRITEL 


L 


a 



Before terminal services can be requested in an application program 
via the DFHTC macro instruction, it is the responsibility of the 
application programmer to provide instructions that do the following: 

1. Symbolically define the TCTTE and TICA by copying the appropriate 
storage definitions (DFHTCTTE and DFHTIOA) provided by CICS. 

(It is assumed that the storage definitions for the CSA and 
TCA have already been copied, as described in the section 
"Storage Definition".) 

2. Establish addressability for the TCTTE and TIOA by specifying 
a symbolic base address for the TCTTE and TIOA, respectively. 
The application programmer must obtain the base address of the 
TCTTE from the TCAFCAAA field of the TCA and place it at TCTTEAR. 
Having established addressability to the TCTTE, he must obtain 
the base address of the TIOA from the TCTTEDA field of the TCTTE 
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and place it at TIOAEAR. The application programmer now has 
access by field name to any field in the TCTTE or TIOA. 

CICS allows one or more TIOA's to be associated with a terminal 
at a given time. If a TIOA is obtained in an application program via 
the DFHSC TYPE-GETMAIN,CLASS=TERMINAL macro instruction, the address 
of the TIOA obtained is automatically placed in the TCASCSA field of 
the TCA. The application programmer must set up a base register for 
this TIOA and must place the address at TCASCSA into the base register. 

The length of the data to be read or written into a given TIOA is 
found in the TIOATDL field of that TIOA. On a read operation, this 
two-byte binary value is placed in the TIOATDL field by Terminal Control 
and represents the number of bytes actually read. On a write operation, 
the application programmer must assign to the TIOATDL field, prior 
to issuing the DFHTC TYPE=WRITE macro instruction, the number of bytes 
to be written. 

Ngte^ All TIOA's have a twelve-byta prefix for storage accounting 

and terminal control and a cne-byte EOB suffix. The value at 
TIOATDL does net include these 13 bytes. 

Given an idle line, CICS always initiates a write before polling 
to read. 

The following are examples of the coding required to (1) acquire 
an output storage area via the DFHSC macro instruction, (2) place the 
address of the storage area acquired into TCTTEDA, (3) place the length 
of the data to be written into TIOATDL, (4) issue a write to a 2260/2265 
terminal, erasing the screen and returning the cursor to the upper 
left corner of the screen before writing, and (5) issue a read from 
a terminal, allowing Terminal Control to manage storage for the TIOA. 



191 Assembler langua ge : 

L TCTTEAR,TCAFCAAA 
DFHSC TYPE^GETMAIN,. 
NUMBYTE=80, 
CLASS=TEEMINAL 
L TIOABAR, TCASCSA 
ST TIOAEAB,TCTTEEA 
MVC TIOADBA(80) , EATA 
MVC TIOATDL, =H , 80» 



ESTABLISH ADDRESSABILITY FOB TCTTE 
OBTAIN TIOA FOR OUTPUT EATA * 

* 

ADDRESS OF TIOA 

PLACE CUTPUT ADDRESS IN TCTTE 

PLACE EATA IN TIOA 

PLACE EATA LENGTH IN TIOATDL 



DFHTC TYPE= (WRITE, ERASE, 

BEAD,«AIT) 
I TIOAEAR,TCTTEEA 



ISSUE WRITE TO 2260/2265 TERMINAL 
ERASE BEFOEE WRITE, THEN READ 
ESTABLISH ADDRESSABILITY FOR TIOA 



For ANS COEOL; 



MOVE TCAFCAAA TO TCTTEAR. 

DFHSC TYPE=GETMAIN, 
NUMBYTE=80, 
CLASS=TERMINAL 

MOVE TCASCSA TC TIOAEAR. 

MOVE TIOAEAR TO TCTTEDA. 

MOVE DATA TO TIOADEA. 

MOVE 80 TO TIOATDL. 



NOTE EST ADDRESSABILITY FOR TCTTE. 
OBTAIN TICA FOE OUTPUT EATA 



NOTE ADDRESS OF TIOA. 

NOTE PLACE ADDE OF TIOA IN TCTTE. 

NOTE PLACE DATA IN TIOA. 

NOTE PLACE DATA LENGTH IN TIOATDL. 
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DFHTC TYPE= (WRITE, ERASE, 

READ, WAIT) 
MOVE TCTTEDA TO TICAEAB 



ISSUE WRITE TO 2260/2265 TERMINAL 
ERASE BEFORE WRITE, THEN READ 
NOTE EST ADDRESSABILITY FOR TIOA. 



1QI P£ZI: 



TCTTEAR=TCAECAAA; 

DFHSC TYPE=GETMAIN, 
NDMBYTE=80, 
CLASS=TERMINAL 

TIOAEAF=TCASCSA; 

TCTTEDA=TICAEAR; 

TIOADEA=DATA; 

TIOATDL=80; 



/♦EST ADDRESSABILITY FOR TCTTE*/ 
CETAIN TICA FOR OUTPUT DATA 



/♦ADDRESS OF TIOA*/ 

/♦PLACE ADDR OF TIOA IN TCTTE*/ 

/♦PLACE DATA IN TIOAV 

/♦PLACE DATA LENGTH IN TIOATDL*/ 



DFHTC TYPE= (WRITE, ERASE, 

READ, WAIT) 
TIOAEAR=TCTTEDA; 



ISSUE WRITE TO 2260/2265 TERMINAL 
ERASE EEEOBE WRITE, THEN READ 
/♦EST ADDRESSABILITY FOR TIOA*/ 



WRITE DATA TO A TERMINAL (WRITE) 

The application programmer can request that data be written to a 
terminal by issuing the 

DFHTC TYPE=WRITE 

macro instruction. Before issuing this macro instruction, he has the 
responsibility to (1) place the address of the TIOA to be written into 
the TCTTEDA field of the TCTTE, and (2) place the length of the data 
to be written into the TICATDL field of the TIOA. (It is assumed that 
he has also symtolically defined the CSA, TCA, and TCTTE and has 
established addressability for the TCTTE.) 

i 
When the write is completed by Terminal Control, the TIOA is released 
to the dynamic storage peel (unless SAVE is specified} since it is 
understood that the application program has no further use for it. 
Any subsequent reference to this TIOA by the application program is 
logically in error and will produce unpredictable results. 

A TIOA can be reused by the application program after a write if 
the request to write data to a terminal is made via the 

DFHTC TYPE= (WRITE, SAVE, WAIT) 

macro instruction. In this case the TIOA is not released by Terminal 
Control. The WAIT parameter is needed to ensure that the write of 
the TIOA is complete before the area is reused. 

Note: To ensure a dump of the TIOA following a Terminal Control write, 
the application programmer must issue a SAVE and WAIT with the 
DFHTC TYPE=WRITE macro instruction that precedes the DFHDC macro 
instruction. 

The application programmer can specify both a write and read 
operation in a single reguest by issuing the 

DFHTC TYPE= (WRITE.READ) 

macro instruction. When this instruction is executed. Terminal Control 

writes the TIOA whose address is at TCTTEDA, waits for that write to 

be completed (an implied wait), and then issues a read from the terminal 
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into the area just used fcr writing. Since the SAVE parameter was 
not specified, one TIOA can be used repeatedly. However, a new TIOA 
is obtained for the read operation and its address placed in TCTTEDA 
when certain devices are involved or when certain conditions exist. 
For example: 

1. 2260 terminals (local and remote) 

2. Local 3270 terminals 

3. PSEUDCEIN is psecified with READ, WRITE 

4. If the TIOA length for the WRITE instruction is less than that 
specified in the DFHTCT TYPE=LINE,TIOAL=length specification 
(binary synchronous terminals) or in the DFHTCT TYPE=LINE, 
INA5EAL=length specification (all other terminals) 

5. Certain error conditions 

6. Osing a 3270 terminal in 2260 compatibility mode 

7. Using terminals with TCAM (CICS/OS only) 

Thus the user should always reload TIOABAR from TCTTEDA following the 
(WRITE, READ) macro instruction. A typical use for the DFHTC 
TYPE= (WRITE, READ) macro instruction is a conversational environment 
where the application program writes a guestion to the terminal, waits 
for a response, and then reads the response. 

Jote: In the case of a terminal connected to the 7770 Audio Response 
Unit, a read reguest that dees not include the WRITE parameter 
causes the "ready" message previously defined in the Terminal 
Control Table to be written to the terminal before the read 
operation occurs. 

If both a write and read operation are specified in a single reguest 
by issuing the 

DFHTC TYPE= (WRITE, READ, SAVE) 

macro instruction, the TIOA used for writing is saved; a new TIOA is 
then dynamically acguired by Terminal Control for the read. The saved 
area remains chained off the TCTTE for the terminal involved and can 
he reused at a later time for either writing or reading. If this TIOA 
is reused later, the application programmer must place the address 
of the TIOA into the TCTTEDA field of the TCTTE prior to issuing the 
reguest to use the area. 

The manner in which the address of a TIOA is "remembered" is 
determined by the application programmer. For example, he can store 
the address in the TWA, or he can rely on the area being accounted 
for in the TIOA storage accounting chain off the TCTTE. 

Open completion of a WHITE, READ, SAVE, the application programmer 
must place the value contained at TCTTEDA into TIOABAR to establish 
addressability for the newly acquired TIOA. 

Note : A WRITE, READ, SAVE may not be usable for the application in 
which the initial TIOA is snail, as determined by the user in 
the Terminal Control Table line entry (TCTLE) during system 
initialization for this line, and in which subsequent TIOA's 
acquired dynamically by CICS are of larger or varying size. 
There is no problem if the user always works with TlOA»s of 
the same size. 

If a write to a 2260/2265 terminal is specified by issuing the 

DFHTC TYPE= (WRITE, ERASE) 
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macro instruction, the screen is erased and the cursor is returned 
to the upper left corner of the screen before writing occurs. If the 
ERASE parameter is omitted, writing begins wherever the cursor is 
located at the time the write is issued. 

Note: The EBASE parameter may be used in conjunction with either the 
WHITE or WRITE1 parameters; it may not be used separately. 
To simply erase the screen, the application programmer might 
(1) place at TCTTEEA the address of storage that contains only 
a start symbol, and (2) issue a DFHTC TYPE= (WRITE, ERASE) macro 
instruction. 

The applicaticn programmer can reguest the positioning of frames 
for a 2760 Optical Image Unit by issuing the 

DFHTC TYPE= (WRITE, OIU) 

macro instruction. See the System Programmer's Reference M anua l for 
an example of an applicaticn program executed as a 2760 transaction. 

When TCAM is used, the applicaticn programmer issues the 

DFHTC IYPE=WRITE, * 

DEST=symbolic name, YES 

macro instruction. See the previous discussion of the DEST operand 
near the beginning of the section "Terminal Services". 

READ DATA FROM A TERMINAL (READ) 

The application programmer can reguest that data be read from a 
terminal by issuing the 

DFHTC TYPE=READ 

macro instruction. Eefore issuing this macro instruction, he can place 
the address of the TTOA into the TCTTE. 

If a TIOA is net provided by the application program, Terminal 
Control attempts to use existing storage if a TIOA is attached to the 
TCTTE, or, if a TIOA is not attached, Terminal Control acguires a new 
TIOA. If the length of the existing TIOA or length of the TIOA provided 
by the applicaticn program is not adeguate, or if other conditions 
exist that make the TIOA unusable, the application program must always 
place the value contained at TCTTEDA into TIOABAR following completion 
of the read to ensure addressability to the correct TIOA. 

A new TIOA is acquired by Terminal Control for the read when the 

DFHTC TYPE= (READ, SAVE) 

macro instruction is issued. All TIOA's currently chained off the 
TCTTE are retained and may be subsequently reused; a new TIOA is 
dynamically acguired for this read (according to the length specified 
in the TCTLE) and is added to the chain. 

Opon completion of a READ, SAVE, the application programmer must 
place the value contained at TCTTEDA into TIOABAR to establish 
addressability for the newly acquired TIOA. The number of bytes read 
is provided by CICS at TIOATDL. 

A read and write operation can be specified in a single request, 
as discussed in the previous topic, "Write Data to a Terminal". 
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SYNCHRONIZE TERMINAL INPUT/OUTPUT FOR A TRANSACTION (WAIT) 



In a transaction where more than one terminal operation is to be 
performed, the application programmer must ensure that the current 
terminal operation is complete before another begins. He can accomplish 
this by issuing the 

DFHTC TYPE=WAIT 

macro instruction, where the WAIT parameter is coded separately, as 
shown, or in combination with READ and/or WRITE. A POT can be coded 
in place of a WRITE,WAIT; a GET can be coded in place of a READ, WAIT. 
A wait should be issued for each read request to ensure that the data 
has been transferred into the TIOA. 

A wait causes the execution of a task (transaction) to be temporarily 
suspended. Indicators are set in the TCT and control is returned to 
CICS. The task resumes processing when the write and/or read is 
complete. 

A wait need not be coded for a write if the write is the last 
terminal operation of the transaction. The TIOA is retained until it 
is written, even though the transaction and its associated storage may 
have already been deleted from the system. 

CONVERSE WITH A TERMINAL (CONVERSE) 

The application programmer can request a conversational mode of 
communication with the terminal by issuing the 

DFHTC TYPE=CONVERSE 

macro instruction, where CONVERSE (or CONV) is the same as WRITE, READ, 
WAIT. The execution of this instruction is always in the sequence: 
WRITE, implied wait, READ, WAIT. In the case of 2260/2265 terminals, 
writing begins wherever the cursor is located at the time this macro 
instruction is issued. 

PAGE DATA TO A TERMINAL (PAGE) 

The application programmer can request a conversational mode of 
communication with a 2260/2265 terminal by issuing the 

DFHTC TYPE=PAGE 

macro instruction, where PAGE is the same as ERASE, WRITE, READ, WAIT. 

FILE SERVICES 

File Management provides the capability, through File Control, to 
read a record from an existing data set (file) on a direct access 
device, update an existing record in a data set, and add a new record 
to a data set. Facilities supported by File Control include indirect 
access, browsing, "duplicates" data sets, and segmented records. Note 
that while File Services supports the user's data base. Transient Data 
Services supports sequential data sets. 

Access methods supported by File Control are the Direct Access Method 
(DAM) and the Indexed Sequential Access Method (ISAM) . DAM can be used 
for fixed- or variable-length records, for blocked or unblocked records, 
and for undefined records. If the user creates DAM data sets and 
describas. them to CICS through the File Control Table (FCT) , application 
programs can access those data sets on a logical 
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record level with File Control providing the blocking/deblocking 
service. 

Optional access to the Data Language/I (DL/I) facility of the IBM 
Information Management System (IMS/360) is also provided under CICS/OS. 
See the section "Reguesting Data Language/I Services" for information 
concerning the use of DL/I in a CICS application program. 

All storage needed for data set operations is acguired by File 
Control in accordance with the data set descriptions previously supplied 
by the user in the FCT. The application programmer need only be 
concerned with the logical record and not with the other characteristics 
of the data set. 

An application program always operates on data in one of two main 
storage areas: (1) a File Input/Output Area (FIOA) or (2) a File Work 
Area (FWA) . A FIOA is required to handle records that are read-only 
and unsegmented or unblocked. A FWA is required to handle records that 
are new, segmented, blocked, or to be updated. In addition, a FWA is 
always used in a browse operation. 

Requests for file services are communicated to File Control via CICS 
macro instructions. File Control then executes, at the priority of 
the requesting program, under control of the reguesting program's TCA, 
saving and restoring registers from this TCA. After the requested file 
service has been provided (or attempted) , control is returned to the 
next executable instruction in the requesting program. Upon return to 
the requesting program, tests can be made and control routed to various 
user-written exception handling routines based on the outcome of the 
reguested file service. 

The File Management macro instruction (DFHFC) is used to request 
any of the following services: 

1. Randomly retrieve data from a data set. 

2. Randomly update or add data to a data set. 

3. Obtain a main storage area to create a new record. 

4. Release main storage area. 

5. Check the response to a request for file services. 

6. Initiate a browse operation. 

7. Sequentially retrieve data from a data set (browse) . 

8. Terminate a browse operation. 

9. Reset the starting location of a browse operation. 
10. Release an update request. 

The following operands can be included in the DFHFC macro 
instruction: 

DFHFC TYPE=GET, * 

DATASET=symbolic name, * 

RDIDADR=symbolic address, * 

SEGSET=symbolic name, YES, ALL, * 

INDEX=symbolic name, YES, * 

TYPOPER=UPDATE, * 

RETMETH=RELREC r KEY, * 

NORESP=symbolic address, * 

DSIDER=symbolic address, * 

SEGIDER=symbolic address, * 

NOTFND=symbolic address, * 

INVREQ=symbolic address, * 

IOERROR=symbolic address, * 

DUPDS=symbolic address, * 
NOTOPEN=symbolic address 
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DFHFC TYPE=PUT, 

RDIDADR=symbolic address, 
SEGSET=YES, 

TYPOPER=NEWREC, UPDATE, 
NORESP=symbolic address, 
DUPREC=symbolic address, 
INVREQ=symbolic address, 
IOERROR=symbolic address, 
NOSPACE=symbolic address, 
NOTOPEN=symbolic address 

DFHFC TYPE=GETAREA, 

DATASET=symbolic name, 
INITIMG=value,YES, 
DSIDER=symbolic address, 
NORESP=symbolic address, 
INVREQ=symbolic address, 
NOTOPEN=symbolic address 

DFHFC TYPE=RELEASE, 

INVREQ=symbolic address 

DFHFC TYPE=SETL, 

DATASET=symbolic name, 
RDIDADR=symbolic address, 
SEGSET=symbolic name, YES, ALL, 
RETMETH=RELREC,KEY, 
NORESP=symbolic address, 
DSIDER=symbolic address, 
SEGIDER=symbolic address, 
INVREQ=symbolic address, 
NOTOPEN=symbolic address 

DFHFC TYPE=GETNEXT, 

SEGSET=symbolic name, YES, ALL, 
NORESP=symbolic address, 
SEGIDER=symbolic address, 
INVREQ=symbolic address, 
IOERROR=symbolic address, 
NOTOPEN=symbolic address, 
ENDFILE=symbolic address 

DFHFC TYPE=ESETL, 

INVREQ=symbolic address 

DFHFC TYPE=RESETL, 

SEGSET=symbolic name, YES, ALL, 
NORESP=symbolic address, 
SEGTDER=symbolic address 



DFHFC TYPE=CH 
NORESP= 
DSTDER= 
SEGIDER 
NOTFND= 
DUPREC= 
INVREQ= 
IOERROR 
DUPDS=S 
NOSPACE 
NOTOPEN 
ENDFILE 



ECK, 

symbolic 

symbolic 

=symboli 

symbolic 

symbolic 

symbolic 

=symboli 

ymbolic 

=symboli 

=symboli 

=symboli 



add 

add 

c ad 

add 

add 

add 

c ad 

addr 

c ad 

c ad 

c ad 



ress, 

ress, 

dress, 

ress, 

ress, 

ress, 

dress, 

ess, 

dress, 

dress, 

dress 
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RANDOMLY RETRIEVE DATA FROM A DATA SET (GET) 

The application programmer can randomly retrieve data from a data 
set (file) by issuing the 

DFHFC TYPE=GET, * 

DATASET=symbolic name, * 

RDIDADR=symbolic address, * 

SEGSET=symbolic name r YES r ALL, * 

INDEX=symbolic name, YES, * 

TYPOPER=UPDATE, * 

RETMETH=RELREC,KEY, * 

NORESP=symbolic address, * 

DSIDER=symbolic address, * 

SEGIDER=symbolic address, * 

NOTFND=symbolic address, * 

INVREQ=symbolic address, * 

IOERROR=symbolic address, * 

DUPDS=symbolic address, * 
NOTOPEN=symbolic address 

macro instruction. This macro instruction is used for random read-only 
(inquiry) or update operations. The requested data record is returned 
in a File Input/Output Area (FIOA) for read-only operations with 
unsegmented, unblocked records; the data record is returned in a File 
Work Area (FWA) for update operations or for read-only operations with 
segmented or blocked records. 

CICS performs the following services in response to a DFHFC TYPE=GET 
macro instruction: 

1. Acquires the main storage area required to read a record. 

2. Reads the requested data. 

3. Locates the requested loqical record . 

In addition, CICS can perform the following services, depending on 
the operands that are included in the DFHFC TYPE=GET macro instruction: 

1. Retrieve a record indirectly. 

2. Segment a record for inquiry (read only) and return the requested 
segments in a work area. 

3. Acquire a File Work Area of the same length as the requested 
record when the record is to be updated or when records are 
blocked or segmented. 

4. Unpack a segmented record into a work area of the same length 
as the requested record. 

Before file services can be requested in an application program via 
the DFHFC TYPE=GET macro instruction, the user must have previously 
defined in the File Control Table (FCT) all data sets referenced by 
the DATASET and INDEX keyword parameters and all segment sets referenced 
by the SEGSET keyword parameter. Instructions must have been provided 
in the application program that symbolically define the FIOA and/or 
FWA by (1) copying the appropriate CICS control section definitions 
(DFHFIOA and DFHFWADS) provided by CICS, and (2) providing his own 
storage definitions for the user's section of the FIOA and/or FWA. If 
ISAM data is being retrieved under CICS/OS, a 16-byte filler must be 
defined prior to the user's data definition. 

The application programmer must specify the parameters he requires 
to retrieve data from a data set. He can do this in either of two 
ways: (1) by including the parameters in operands of the DFHFC TYPE=GET 
macro instruction, or (2) by coding instructions, prior to issuing the 
DFHFC TYPE=GET macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in 
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operands of the DFHFC TYPE=GET macic instruction, the applicable 
keywords are EATASET, RBIEADR, SEGSET, INDEX, TYFOPER, and RETMETH. 

After file services have been requested in an application program, 
addressability must be established for the required FIOA and/or FWA. 
The address of the area involved, provided by CICS at TCAFCAA, must 
he placed at FICAEAR and/or FWACBAR. The user may issue a DFHSC 
TYPE=EREEMAIN or a DFHFC TYPE=RELEASE macro instruction to free the 
FIOA or FWA, otherwise CICS will free the area upon task termination. 

If the application programmer desires to check the response to his 
request to retrieve data from a data set, he must specify the entry 
labels (symbolic addresses) he requires to access user-written exception 
handling routines. He can do this in any of three ways: (1) by 
including the entry labels in operands of the DFHFC TYPE=GET macro 
instruction, (2) by codinq instructions immediately following the DFHFC 
TYPE=GET macro instruction that examine the response code provided 
by CICS at TCAFCTR (TCAFCRC if the language is ANS COBOL) and transfer 
control to the appropriate routine, or (3) by including the entry 
labels in the DFHFC TYPE=CHECK macro instruction (which must immediately 
fellow the DFHFC TYPE=GET macro instruction) . In any case, the 
applicable keywords are NCRESP, DSIDER, ST.GIDER, NOTFND, INVREQ, 
ICERROR, DUPDS, and NCTCEEN. m 

A discussion of the operands that can be included in the DFHFC 
TYPE=GET macro instruction fellows. (The keywords used to access user- 
written exception handlinq routines are discussed in the section "Test 
Response to a Request for File Services".) 

DATASET: This operand is used to specify the symbolic name of the 
primary data set to be accessed. The symbolic name must have been 
previously defined in the File Control Table (FCT) . If the operation 
involves indirect accessing, the symbolic data set name specified by 
this operand represents the primary (tarqet) data set from which a 
record is tc he retrieved. This operand can be omitted if the 
application programmer has previously placed the symbolic name in the 
TCAFCDI field of the TCA. 

REIDADR: This operand is used to specify the symbolic address of the 
user's Record Identification field that contains the key of the record 
to be retrieved, as required by ISAM, or the block reference field, 
as required by DAM. This operand can be omitted if the application 
programmer has previously placed the address of the field in the TCAFCRI 
field of the TCA. For further details, see the section "Data Base 
Considerations". 

Note: There must be a unique Record Identification field for each 
data set that is to be concurrently updated by a single 
application program. Because CICS application programs must 
have the quality of quasi-reentrance, it is highly recommended 
that the Record Identification field not reside in the 
application program. 

SEGSET: The SEGSET=name operand is used to specify the symbolic name 
of the seqment set to be retrieved. The symbolic name must have been 
previously defined in the associated Seqment Control section of the 
File Control Table (FCT) . 

SEGSIT=YES is used when reading a segmented record if the application 
programmer has previously placed the symbolic name of the segment set 
in the TCAFCSI field of the TCA. 
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SEGSET=ALL is used when reading a segmented record if the entire 
logical record is desired in an unpacked and aligned format. SEGSET=ALL 
is automatically used by CICS when updating a segmented record. The 
entire logical record is unpacked and returned to the application 
program. 

If the SEGSET operand is omitted, and the GET is from a segmented 
data set, the logical record is returned in its packed format. 

INDEX: The INDEX=name operand specifies the symbolic name of the 
highest level index data set used in an Indirect Access hierarchy of 
ISAM and/or DAM data sets. (This index data set is the first data 
set accessed in the hierarchy.) The symbolic name must have been 
previously defined in the FCT. INDEX=YES must be coded if the 
application programmer has previously placed the synbolic name in the 
TCAFCAI field of the TCA. If the index data set is a DAM data set, 
it cannot be blocked. 

TYPOPER: The TYPOPER=UPDATE operand is used when a record is to be 
obtained for updating. To free the area used, a DFHFC TYPE=RELEASE 
or DFHFC TYPE=PUT must be issued^ If the TYPOPER=OPEATE operand is 
omitted, a read-only operation is assumed. If the record being updated 
is from a blocked DAM data set, the RETMETH operand must also be 
specified. If the application program is to update more than one data 
set concurrently, a separate Record Identification field (RDIDADR) 
must be specified for each update request. 

RETMETH: The RETMETH operand applies only to blocked DAM data sets 
and is used to specify the argument type (deblocking method) for the 
deblocking of the data sets. The RETMETH=RELREC operand specifies 
that retrieval is to occur by relative record, where the first record 
in a block is record zero. The RETMETH=KEY operand specifies that 
retrieval is to occur by key. The RETMETH operand must be specified 
if TYEOPER=tJPDATE is present. 

If the RETMETH keyword is emitted and a reguest to read a blocked 
DAM data set is issued, the entire physical record (block) is returned 
to the requesting program in the FIOA. 

The user's block reference field, required by DAM, contains the 
criteria for the deblocking of DAM data sets. For further details, 
see the section "Data Base Considerations". 

Note: If the record being retrieved is "undefined", it is the user's 
responsibility to determine the length of the record. 

The following are examples of the coding required to do a random 
read-only (inquiry) operation on a record of the master data set, 
assuming blocked or segmented records. 
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Z.9.R Assembler languacje: 

COPY DFHTCADS 

KEY DS CL8 

FWACBAR EQU 7 

COPY DFHFWADS 

RECORD DS 0CL350 



PageofSH20-1047-4 
Revised April 11, 1973 
ByTNLSN20-9012 



COPY TCA SYMBOLIC STRG DEFN 
RECORD IDENT FIELD IN TWA 
ASSIGN BASE REGISTER FOR FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
FIELD AND HAS SAME BASE REGISTER 



MVC KEY,ACCTNO 
READREC DFHFC TYPE=GET, 

DATASET=MASTERA, 
RDIDADR=KEY 

L FWACBAR,TCAFCAA 



MOVE RECORD IDENT TO KEY FIELD 
GET RECORD FROM MASTER DATA SET 



ESTABLISH ADDRESSABILITY FOR FWA 



For ANS COBOL: 

02 FWACBAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA, 



01 DFHTCADS COPY DFHTCADS. 
02 KEYF PICTURE X(8) . 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA, 
NOTE DEFINE KEY FIELD IN TWA. 



01 DFHFWADS COPY DFHFWADS. 

02 RECORD PICTURE X(350). 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFINE RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



NOTE ESTABLISH TCA ADDRESSABILITY 



MOVE ACCTNO TO KEYF. 
READREC. 

DFHFC TYPE=GET, 

DATASET=MASTERA, 
RDIDADR=KEYF 
MOVE TCAFCAA TO FWACBAR. 



NOTE MOVE RECORD IDENT TO KEY. 
GET RECORD FROM MASTER DATA SET 

NOTE ESTABLISH FWA ADDRESSABILITY. 



For PL/I: 

7oINCLUDE DFHTCADS; 

02 KEY CHAR (8) ; 
^INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/*COPY SYMBOLIC STRG DEFN FOR TCA*/ 
/*DEFINE KEY FIELD IN TWA*/ 
/*COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/*DEFINE RECORD LAYOUT IN FWA*/ 



KEY=ACCTNO; 

READREC: 

DFHFC TYPE=GET, 

DATASET=MASTERA f 
RDIDADR=KEY 

FWACBAR=TCAFCAA; 



/*ASSIGN RECORD IDENT TO KEY FIELD*/ 
GET RECORD FROM MASTER DATA SET 



/♦ESTABLISH ADDRESSABILITY FOR FWA*/ 



The following are examples of the coding required to randomly 
retrieve a record for update on the master data set. 
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PageofSH20-1047-4 
Revised April 11, 1973 
ByTNLSN20-9012 

I.9.L Assembler language: 



COPY DFHTCADS 

KEY DS CL8 

FWACBAR EQU 7 

COPY DFHFWADS 

RECORD DS 0CL350 



COPY TCA SYMBOLIC STRG DEFN 
DEFINE KEY FIELD IN TWA 
ASSIGN BASE REGISTER FOR FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
FIELD AND HAS SAME BASE REGISTER 



MVC KEY,ACCTNO 
READUPD DFHFC TYPE=GET, 

DATASET=MASTERA, 
RDIDADR=KEY, 
TYPOPER=UPDATE 
L FWACBAR, TCAFCAA 



MOVE RECORD IDENT TO KEY FIELD 
GET RECORD FROM MASTER DATA SET 
FOR UPDATE 



ESTABLISH ADDRESSABILITY FOR FWA 



For ANS_ COBOL: 

02 FWACBAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA 



01 DFHTCADS COPY DFHTCADS. 
02 KEYF PICTURE X (8) . 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA, 
NOTE DEFINE KEY FIELD IN TWA. 



01 DFHFWADS COPY DFHFWADS. 

02 RECORD PICTURE X(350) 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFINE RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



NOTE ESTABLISH TCA ADDRESSABILITY, 



MOVE ACCTNO TO KEYF. 
READREC. 

DFHFC TYPE=GET, 

DATASET=MASTERA, 
RDIDADR=KEYF 
MOVE TCAFCAA TO FWACBAR. 



NOTE MOVE RECORD IDENT TO KEY FIELD. 
GET RECORD FROM MASTER DATA SET 

NOTE ESTABLISH FWA ADDRESSABILITY. 



For PL/I: 

%INCLUDE DFHTCADS; 

02 KEY CHAR (8) ; 
%INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/*COPY SYMBOLIC STRG DEFN FOR TCA*/ 
/♦DEFINE KEY FIELD IN TWA*/ 
/*COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE RECORD LAYOUT IN FWA*/ 



KEY=ACCTNO; 

READREC: 

DFHFC TYPE=GET, 

DATASET=MASTERA, 

RDIDADR=KEY r 

TYPOPER=UPDATE 

FWACBAR=TCAFCAA; 



/*ASSIGN RECORD IDENT TO KEY FIELD*/ 
GET RECORD FROM MASTER DATA SET * 

/♦ESTABLISH ADDRESSABILITY FOR FWA*/ 
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*• *Elfe" f cllowing are examples of the coding required to randomly 
retrieve a record for update where the key for the desired record is 
unknown. A cross-index data set containing the master key is available, 
making it possitle to access the record indirectly, 



IQI Assembler language: 



COPY DFHTCADS 

KEY DS CI25 

FWACEAR EQU 7 

COPY DFHEWADS 

EECORD BS 0CL350 



COPY TCA SYHEOLIC STRG DEFN 
DEFINE KEY FIELD IN TWA 
ASSIGN BASE REGISTER FOR FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
FIELD AND HAS SAME BASE REGISTER 



MVC KEY,INBEXA 
BEADING DFHFC TYPE-GET, 

DATASE1=MASTERA, 
RDIEADR=KEY, 
TYPOPER=UPEATE, 
INBEX=INDIRECT 

L FWACEAR, TCAECAA 



MOVE INDEX IDENT TO KEY FIELD 
GET RECOED FROM MASTER LATA SET 
BY FIRST ACCESSING A CROSS-INDEX 
DATA SET NAMED INDIRECT 



ESTABLISH ADDRESSABILITY FOR FWA 



I2L ANS COEOL: 

02 FWACBAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER. 



01 DFHTCADS COPY DFHTCADS 
02 KEY PICTURE X(25) . 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA 
NOTE DEFINE KEY FIELD IN TWA. 



1 DFHFWAES COPY EFHFWADS. 

02 RECORD PICTURE X(350) 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA. 
NOTE DEFINE RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACBTA TO TCACBAR. 



NOTE ESTABLISH TCA ADDRESSABILITY, 



MOVE PARTNAME TO KEY. 
EEADREC. 

DFHFC TYPE=GET, 

DATASET=MASTERA, 
REIEADB=KEY, 
TYPOPER=UPBATE, 
INDEX=INDEXAB 
MOVE TCAFCAA TO FWACBAR. 



NOTE MOVE INDEX IDENT TO KEY. 

GET RECORD FROM MASTER DATA SET 
EY FIRST ACCESSING A CROSS-INDEX 
DATA SET NAMED INDEXAB 



NOTE ESTABLISH FWA ADDRESSABILITY, 
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IQH RLZI' 



^INCLUDE DFHTCADS; 

2 KEY CHAR (25) ; 
^INCLUDE DFHFWADS; 

02 EECORD CHAR (350) ; 



/*COFY SYMBOLIC STRG DEFN FOR TCA*/ 
/♦DEFINE KEY FIELD IN TWA*/ 
/♦COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE RECORD LAYOUT IN FWA*/ 



KEY=PARTNAME; 

F1ADREC: 

DFHFC TYPE=GST, 

DATASET=MASTERA, 
RDIEADR=KEY, 
TYPOPER=UPEATE, 
INDEX=INDEXAB 

FWACBAR=TCAFCAA; 



/♦ASSIGN EECORD INDENT TO KEY FIELD*/ 

GET RECORD FROM MASTER DATA SET ♦ 
BY FIRST ACCESSING A CROSS-INDEX ♦ 
DATA SET NAMEE INDEXAB . ♦ 

* 

/♦ESTABLISH ADDRESSABILITY FOR FWA*/ 



RANDOMLY UPDATE OR AEE EATA TO A DATA SET (PUT) 

The application programmer can randomly update or add data to a 
data set (file) by issuing the 

DFHFC TYPE=PUT, 

RDTDADR=symbclic address, 
SEGSET=YES, 

TYFOPER=NEWR EC, UPDATE, 
NCBE£P=syrabolic address, 
DUPREC=symbolic address, 
INVREQ=syotolic address, 
IOERROR=symbclic address, 
NOSPACE=symbclic address, 
NCTCFEN=symbclic address 

macro instruction. This macro instruction is used to (1) update an 
existing record, which has been previously retrieved via the DFEFC 
1YPE=GET,TYPOFEB=UPDATE macro instruction, or (2) add a new record 
to an existing data set. Note that a DFHFC TYPE-PUT macro instruction 
must never be issued without first issuing a DFHFC TYPE=GET or DFHFC 
TYPE=GETAREA macro instruction, or unpredictable results will occur. 

A File Work Area (FWA) is used tc contain the record or segments 
to be written or updated. The first 16 bytes of this work area are 
the CICS control section followed by the actual record or segments. 

CICS performs the following services in response to a DFHFC TYPE=PUT 
macro instruction: 

1. Writes updated cr new records on user-defined data sets 

2. Acquires or locates the main storage and control blocks required 
to write the record 

3. Releases all data set storage associated with the reguest to 
write 

4. Packs a segmented record, depending en the data set organization 
and the operands included in the DFHFC TYPE=PUT macro instruction 

Before file services can be requested in an application program 
via the DFEFC TYPE=PUT macro instruction, the user must have previously 
defined in the File Ccntrcl Table (FCT) all data sets referenced by 
the DATASET keyword parameter and all segment sets referenced by the 
SEGSET keyword parameter. The application programmer must have provided 
instructions that do the following: 
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1. Symbolically define the FWA by (1) copying the appropriate 
storage definition (DFHFWADS) provided by CICS, or (2) providing 
his cwn storage definition for the FWA. 

2. Establish addressability for the new FWA by specifying a symbolic 
base address for the FWA. 

3. Place the address of the FWA in the TCA at TCAFCAA. This address 
is provided by CICS in response to a previous DFHFC TYPE=GET 

or DFHFC TYPE=GFTAREA reguest. 

The application programmer must specify the parameters he reguires 
to PUT data to a data set. He can do this in either of two ways: (1) 
ty including the parameters in operands of the DFHFC TYPE=POT macro 
instruction, or (2) by coding instructions, jrior to issuing the DFHFC 
TYPE=PUT macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in operands of 
the EFHFC TYPE=PUT macro instruction, the applicable keywords are 
RDIEADR, SEGSET, and TYPOPER. 

If the records being written to a data set are undefined, the 
application prograirmer must place the length of the record being written 
in the TCA at TCAFCURL. 

A discussion of the operands that can be included in the DFHFC 
TYPE=PDT macro instruction fellows. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Reguest fdr File Services 1 '.) 

REICABR: This operand is used to specify the symbolic address of the 
user's data field that contains the key, as reguired by ISAM, or the 
block reference field, as reguired by DAM, of the record to be written. 
This operand can be omitted if the application programmer has previously 
placed the symbolic address in the TCAFCRI field of the TCA. Note 
that this operand must not reference a field in the FWA as the FWA 
might be freed before the actual write occurs. 

SEGSE1: The SEGSE1=YES operand is used when a data set containing 
segmented records is to be added to or updated. If this operand is 
omitted. File Control does not perform its normal packing operation 
en segmented records. 

TYPOPER: The TYPCPER=NEWBEC operand must be used when adding a new 
record to an existing data set. If this operand is omitted, the default 
is TYPOPER=UPDATE in which case the DFHFC TYPE=GET,TYPOPER=UPDATE macro 
instruction must precede the EFHFC TYPE=PUT reguest. 

If the application programmer desires to check the response to his 
reguest to retrieve data from a data set, he must specify the entry 
labels he reguires to access user-written error handling routines. 
He can do this in any of three ways: (1) by including the entry labels 
in operands of the DFHFC TYPE=POT macro instruction, (2) by coding 
instructions immediately following the DFHFC TYPE=PUT macro instruction 
that examine the response cede provided by CICS at TCAFCTR (TCAFCRC 
if the language is ANS COBOL) and transfer control to the appropriate 
routine, or (3) by including the entry labels in the DFHFC TYPE=CHECK 
macro instruction (which usually immediately fellows the DFHFC TYPE=PUT 
macro instruction) . In any case, the applicable keywords are NORESP, 
EOPREC, INVBEC, IOEEFOR, NOSPACE, and NOTCFEN. 

The following are examples of the coding reguired to randomly 
retrieve a record for updating and then return that record to the data 

set. 
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1QL Assembler lancjuaae: 



COPY DFHTCADS 

KEY DS CL8 

FWACBAR EQU 7 

COPY DFHFWADS 

EECORD ES 0CL350 



COPY TCA SYMBOLIC STRG DEFN 
DEFINE KEY FIELD IN TWA 
ASSIGN BASE REGISTER FOB FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
PIELD AND HAS SAME BASE REGISTER 



5EADUPD DFHFC TYPE=GET, 

DATASET=MASTERB, 
BDIEADR=KEY, 
TYECFER=UPDATE 
L FWACBAR,TCAECAA 

(update record) 

ST FWACBAR, TCAECAA 
WRITEUP DFEFC TYEE=PUT, 

REIEADR=KEY 



READ RECORD FOB UPDATE 



ESTABLISH ADDRESSABILITY FOR FWA 



PLACE FWA ADDRESS IN TCA 
WRITE THE UPIATED RECORD 



lor ANS COBOL: 

02 FWACEAR PICTURE SS (8) . 



USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA. 



01 DFHTCADS COPY DFHTCADS. 
02 KEY EICTURE X(8) . 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA. 
NOTE DEFINE KEY FIELD IN TWA. 



1 DFHFWAES COPY DFHFWADS. 

02 RECORD EICTURE X(350) 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFINE RECORD LAYOUT IN FWA. 



EEOCEDURE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



NOTE ESTABLISH TCA ADDRESSABILITY. 



READUPD. 

DFHFC TYPE=GET, 

DATASET=MASTERB, 
RDIDADR=KEY, 
TYPOPER=UPDATE 
MOVE TCAFCAA TO FWACBAR. 

(update record) 

MOVE FWACEAR IC TCAFCAA. 
WRITEUP. 

DFHFC TYPE=PUT, 

REIEADR=KEY 



READ RECORD FOR UPDATE 



NOTE ESTABLISH FWA ADDRESSABILITY. 



NOTE MOVE ADDRESS OF FWA TO TCA. 
WRITE THE UPEATED RECORD * 



12E 2LZI' 

^INCLUDE DFHTCADS; 

02 KEY CHAR (8) ; 
^INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/♦COPY SYMBOLIC STRG DEFN FOR TCA*/ 
/♦DEFINE KEY FIELD IN TWA*/ 
/♦COPY SYMBOLIC STRG DEFN FOR FWAV 
/♦DEFINE RECORD LAYOUT IN FWAV 
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READOP: 

DFEFC TYPE=GET, BEAD RECORD FOR UPDATE * 

DATASET=MAST£RB, * 

RDIEADR=KEY, * 

TYPOFEB=UPEATE 

FWACBAR=TCAFCAA; /*ESTAELISH ADDRESSABILITY FOB FWA*/ 

• 

(update record) 

TCAFCAA=FWACEAR; /*PLACE ADDS OF WORK AREA IN TCA*/ 

WBITEOP: 

DFHFC TYPE=PUT, WRITE THE UPIATEE RECORD * 

BEIEADB=KEY 

OETAIN A FIIE WORK AREA (GETAREA) 

The application programmer can obtain an area of main storage to 
create a new record for a data set by issuing the 

DFHFC TYPE=GETAREA, * 

DATASET=syrabclic name, * 

IWITIMG=value,YES, * 

DSIDER=symbclic address, * 

N0BE5P=symbolic address, * 
INVREQ=symbolic address, . * 
NOTCEEN=symbclic address 

macro instruction. The new main storage area is a File Work Area (FWA) 
and can only be obtained through a DFHFC TYPE=GETAREA request. (A 
Storage Control DFHSC TYP£=GETMAIN reguest cannot be used for file 
operations.) 

CICS performs the following services in response to a DFHFC 
TYPE=GETAREA macro instruction: 

1. Acquires main storage (an FWA) for the creation of a new record. 

2. Includes and initializes the FWA control fields (a 16-byte 
prefix to the FWA) required by File Control. 

Before the DFHFC TYPE=GETAREA is used in an application program, 
the user must have previously defined in the File Control Table (FCT) 
all data sets referenced by the DATASET keyword parameter. The 
application programmer must have provided instructions that do the 
following: 

1. Symbolically define the FWA by (1) copying the appropriate 
storage definition (DFHFWADS) provided by CICS, or (2) providing 
his own storage definition for the FWA. 

2. Establish addressability for the new FWA by specifying a symbolic 
base address for the FHA. (The address of the area involved, 
returned by CICS at TCAFCAA, must be placed at FWACBAR.) 

The application programmer must specify the parameters he requires 
to obtain a FWA. He can do this in either of two ways: (1) by including 
the parameters in operands of the DFHFC TYPE=GETAREA macro instruction, 
or (2) by coding instructions, .prior to issuing the DFHFC TYPE=GETAREA 
macro instruction, that dynamically move these parameters to fields 
in the TCA. If the parameters are included in operands of the DFHFC 
TYPE=GETAREA macro instruction, the application keywords are DATASET 
and IHITIHG. 
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If the application programmer desires to check 
request tc obtain a FWA, he must specify the entry 
addresses) he requires to access user-written erro 
He can do this in any of three ways: (1) by includ 
in operands of the DFHFC TYPE=GETAREA macro instru 
instructions immediately following the DFHFC TYPE= 
instruction that examine the response code provide 
(TCAFCRC if the language is ANS CCBCL) and transfe 
appropriate routine, or (3) by including the entry 
TYPE=CHECK macro instruction (which usually immedi 
CFHFC TYPE=GETABEA macro instruction) . In any cas 
keywords are DSIDER, NOBESP, INVSEQ, and HOTCEEN. 



the response to his 

labels (symbolic 
r handling routines. 
ing the entry labels 
ction, (2) by coding 
GETAREA macro 
d by CICS at TCAFCTR 
r control to the 

labels in the DFHFC 
ately follows the 
e, the applicable 



A discussion of the operands that can fce included in the DFHFC 
TYPE=GETAREA macro instruction follows. (The keywords used to access 
user-written exception handling routines are discussed in the section 
"Test Response to a Request for File Services".) 

DATASET: This operand is used to specify the symbolic name of the 
data set (file) to be accessed. The symbolic name must have been 
previously defined in the File Control Table (FCT) . This operand can 
re omitted if the application programmer has previously placed the 
symbolic name in the TCAFCDI field of the TCA. 

INITIMG: • The INITIMG=value operand is used, at the option of the 
application programmer, to specify a one-byte hexadecimal initialization 
value for the FWA acquired by File Control. INITiMG=YES must be used 
if the application programmer has previously placed the initialization 
value in the TCASCIB field of the TCA. 

If the INITIMG keyword is omitted, the FWA is initialized to EBCDIC 
tlanks (X"40»).' * . " 

4 

The following are examples of the coding required to obtain a FWA, 
build a new record in the FWA, and then write the record to a data 
set. 



For Assembler lang uag e: 



COPY DFHTCADS 

KEY DS CL8 

FWACEAR EQD 7 

COPY DFHFiiADS 

IECORD DS 0C1350 



COPY TCA SYMBOLIC STRG DEFN 
DEFINE KEY FIELD IN THA 
ASSIGN BASE REGISTER FOR FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
FIELD AND HAS SAME BASE REGISTER 



NEWREC DFHFC TYPF=GETAREA, 

DATASEI=MASTFRC 
L FWACEAR, TCAJCAA 

(build new record) 



OBTAIN A FWA TO CREATE A NEW 

RECORD FOR A DATA SET 

ESTABLISH ADDRESSABILITY FOR FWA 



ST FWACBAR,TCAFCAA 
WRITNEW DFF.FC TYEE=PUT, 

TYPCEER=NEHBEC, 
REIEADR=KEY 



PLACE ACDR OF NEW RECORD IN TCA 
WRITE THE NEW RECORD 
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For ANS COBOL: 

02 FWACBAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA, 



01 DFHTCADS COPY DFHTCADS. 
02 KEY PICTURE X(8) . 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA, 
NOTE DEFINE KEY FIELD IN TWA. 



01 DFHFWADS COPY DFHFWADS. 
02 RECORD PICTURE X(350). 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFIN-E RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACBAR. 



NOTE ESTABLISH TCA ADDRESSABILITY 



NEWREC. 

DFHFC TYPE=GETAREA, 

DATASET=MASTERC 
MOVE TCAFCAA TO FWACBAR. 



OBTAIN A FWA TO CREATE A NEW 

RECORD FOR A DATA SET 

NOTE ESTABLISH FWA ADDRESSABILITY, 



(build new record) 



MOVE FWACBAR TO TCAFCAA. 
DFHFC TYPE=PUT, 

TYPOPER=NEWREC r 
RDIDADR=KEY 



NOTE ADDRESS OF NEW RECORD TO. TCA. 
WRITE THE NEW RECORD 



lor PL/I: 

%INCLUDE DFHTCADS; 

02 KEY CHAR(8) ; 
%INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/*COPY SYMBOLIC STRG DEFN FOR TCA*/ 
/*DEFINE KEY FIELD IN TWA*/ 
/*COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/*DEFINE RECORD LAYOUT IN FWA*/ 



NEWREC: 

DFHFC TYPE=GETAREA r 

DATASET=MASTERC 
FWACBAR=TCAFCAA; 



OBTAIN A FWA TO CREATE A NEW 

RECORD FOR A DATA SET 

/*ESTABLISH ADDRESSABILITY FOR FWA*/ 



(build new record) 



TCAFCAA=FWACBAR; 
WRITNEW: 

DFHFC TYPE=PUT, 

TYPOPER=NEWREC f 
RDIDADR=KEY 



/*PLACE ADDR OF NEW RECORD IN TCA*/ 



WRITE THE NEW RECORD 



RELEASE FILE STORAGE (RELEASE) 

The application programmer can release the storage areas acquired 
for File Control operations by issuing the 

DFHFC TYPE=RELEASE, 

INVREQ=symbolic address 
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macro instruction. This macro instruction is primarily used when (1) 
a record has been retrieved for update, (2) it is determined that the 
update should not occur, and (3) it is desired to release all 
encumbrances associated with the update operation (that is, FWA, FIOA, 
exclusive control) . 

Note: In the case of response codes X«01« (DSIDER) , X'OU' (SEGIDER) , 
X'03' (INVREQ) , X'OC (NOTOPEN) , CICS does not acquire an FIOA; 
therefore TCAFCAA does not contain an FIOA address. 

To release the storage occupied by a FWA or FIOA that was returned 
to a read, either a DFHFC TYPE=RELEASE or DFHSC TYPE=FREEMAIN macro 
instruction should be issued. However, if a "read for update" request 
results in an error, the FIOA is returned to the user; a DFHFC 
TYPE=RELEASE macro instruction should then be issued to release any 
exclusive control emcumbrances. 

The DFHFC TYPE=RELEASE macro instruction must not be specified if 
the DFHFC TYPE=PUT macro instruction is used to write an updated record 
back to a data set. 

CICS performs the following services in response to a DFHFC 
TYPE=RELEASE macro instruction: 

1. Releases a FWA and/or FIOA. 

2. Releases exclusive control of a record retrieved for update (if 
applicable) . 

Before the DFHFC TYPE=RELEASE macro instruction is executed, the 
application programmer must ensure that the address of the FWA to be 
released has been placed in the TCA at TCAFCAA. The FIOA (if any) 
associated with it is also released. In addition, the correct record 
identification must be present in the Record Identification field 
specified in the RDIDADR operand of the DFHFC TYPE=GET macro 
instruction . 

The FWA and FIOA are automatically released at termination of the 
task, if not released earlier in response to to this macro instruction. 

If the application programmer desires to check the response to his 
request to release a FWA or FIOA, he must specify the entry label 
(symbolic address) he requires to access the user-written exception 
handling routine. He can do this in any of three ways: (1) by including 
the INVREQ operand in the DFHFC TYPE=RELEASE macro instruction, (2) by 
coding an instruction immediately following the DFHFC TYPE=RELEASE 
macro instruction that examines the response code provided by CICS at 
TCAFCTR (TCAFCRC if the language is ANS COBOL) and transfers conrol to 
the appropriate routine, or (3) by including the INVREQ operand in the 
DFHFC TYPE=CHECK macro instruction (which usually immediately follows 
the DFHFC TYPE=RELEASE macro instruction) . In any case, the applicable 
keyword is INVREQ. 

For a discussion of the INVREQ keyword, see the section "Test 
Response to a Request for File Services". 

The followinq are examples of the codinq required to request the 
release of a FWA. 



Z9.L Assembler language: 

FWACBAR EQU 7 

COPY DFHFWADS 
RECORD DS 0CL350 



ASSIGN BASE REGISTER FOR FWA 
SYMBOLICALLY DEFINE FWA 
RECORD LAYOUT FOLLOWS CONTROL 
FIELD AND HAS SAME BASE REGISTER 
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ST FWACBAR,TCAFCAA ADDRESS OF FWA TO BE RELEASED 
DFHFC TYPE=RELEASE IN TCA AND ISSUE RELEASE REQUEST 
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For ANS CCECI: 

02 FWACBAR PICTURE S9 (8) OSAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOB FWA. 



01 DFHTCADS COPY DFHTCADS. 
02 RECCRB PICTURE X (350) 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFINE RECORD LAYOUT IN FWA. 



EEOCEBURE DIVISION. 

MOVE CSACDTA TO TCACEAR. 



NOTE ESTABLISH TCA ADDRESSABILITY, 



MOVE FWACBAR TO TCAFCAA. 

EISEREC. 

DFHFC TYPE=RELEASE 



NOTE ADDE OF FWA TO EE RELEASED. 
ISSUE RELEASE REQUEST 



121 JZI/.I- 

^INCLUDE DFHTCADS; 



/♦COPY SYMBOLIC STRG DEFN FOR TCA*/ 



^INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/♦COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE RECORD LAYOUT IN FWA*/ 



TCACEAR=CSACDIA; 
TCAFCaA= FWACBAR; 

ELSEREC: 

DFHFC TYPE=RELEASE 



/♦ESTAELISH ADDRESSABILITY FOR TCA*/ 
/♦ADDRESS OF FWA TO BE RELEASED*/ 

ISSUE RELEASE REQUEST 



INITIATE SEQUENTIAL RETRIEVAL (SEIL) 



The application programmer initiates a sequential retrieval operation 
en a data set by issuing the 



DFKFC TYPE=SETI, 

EATASET=syrabolic name, 
RDIDADR=symbclic address, 
SEGSET=symbolic name, YES, ALL, 
EETMETH=RELREC,KEY, 
NCEESP=symbclic address, 
DSIDER=symfcclic address, 
SEGIDER=symtclic address, 
INVREO=symtclic address, 
NCTCPEN=symbclic address 

macro instruction. This macro instruction is used enly to initiate 
a sequential retrieval operation and must be issued before any GETNEXT 
macro instruction. It is used to establish the starting position 
within the data set where the browse operation is to begin. 

Records are always returned to the application program in a File 
WorX Area (FWA) . The FWA returned by CICS following a SETL request 
is unique for the duration of that particular sequential operation. 
Should the application program issue another SETL request, for the 
same cr another ^ata set, a different FWA will be created by CICS. 
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Thus it is possible for a single application program to be concurrently 
browsing the same data set at several different locations. 

Note that during a browse operation on a segmented data set, the 
original FWA (that is, the one allocated by the SET! reguest) may be 
replaced with a different FWA if a segment set specified in a GETNEXT 
reguest requires a larger FWA than the segment set specified in the 
SETI reguest. In this situation, the application programmer should 
not rely on the same FWA being returned from a GETNEXT reguest as was 
specified when the GETNEXT reguest was issued. The address of the 
appropriate FWA is always located in the TCA field labeled TCAFCAA 
upon return from a GETNEXT reguest. 

CICS performs the following services in response to a DFHFC TYPE=SETL 
macro instruction: 

1. Acquires the main storage I/O areas and work areas to be 
associated with this browse operation. 

2. Preserves the segment set name (if any) as the default segment 
set to be used if none is specified in subsequent GETNEXT 
reguests. 

3. Returns the FWA address in the TCA field labeled TCAFCAA. 

Before the SETL loacro instruction can be used, the user must have 
previously defined in the File Control Table (FCT) the data set 
referenced by the DATASET operand and all segment sets referenced by 
the SEGSET operand. The application programmer should have also 
provided instructions which do the following: 

1. Symbolically define the FWA by (1) copying the CICS control 
section definition (DFHFWACS) provided by CICS, and (2) providing 
his own storage definition for the user's section of the FWA. 

2. Establish addressability for the FWA by specifying a symbolic 
base address for the FflA, typically following the DFHFC macro 
instruction. (The address of the FWA, provided by CICS at 
TCAFCAA, must be placed at FWACBAR upon normal return from the 
SETI.) 

A discussion of the operands that can be used with the DFHFC 
TYPE=SETL macro instruction fellows. (The keywords used to specify 
user-written exception handling routines are discussed in the section 
"Test Response to a Request for File Services". These keywords include 
HOBESP, DESIDFR, SEGIDER, INVBEQ, and NOTCPEN.) 

DATASET: This operand is used to specify the symbolic name of the 
data set en which sequential retrieval is to be initiated. The symbolic 
name must have been previously defined in the File Control Table (FCT) . 
This operand can be omitted if the application programmer has previously 
placed the symbolic data set name in the TCA field labeled TCAFCDI. 

BEIDADR: This operand specifies the symbolic address of the user's 
Fecord Identification field which contains the specific or generic 
(partial) key as required by ISAM, or the block reference as required 
by DAM. This operand can be omitted if the application programmer 
has previously placed the address of the field in the TCAFCRI field 
of the TCA. A generic key is one in which the user supplies only the 
significant characters of a desired group of keys, padding the remainder 
of the key field with blanks or binary zeros. 

For an ISAM data set, the browse operation begins at the first 
record with a key equal to or higher than the key provided in the 
user's Record Identification field. For example, a generic key 
specification of "D6420000" would cause sequential processing to begin 
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at the first record with a key containing D642xxxx, regardless of the 
characters represented by the x*s. (A key field of all binary zeros 
would therefore cause sequential processing to begin at the first 
logical reccrd of the data set.) 

For a DAM data set, the user's Record Identification field must 
contain a specific block reference (for example, TTR, MBBCCHHR, etc.) 
which conforms to the acceptable addressing method defined for that 
data set. (For further details, refer to the section "Data Base 
Considerations".) Processing begins -with the specified block and 
continues with each subseguent block until the browse operation is 
terminated. If the DAM data set contains blocked records, processing 
begins at the first logical record of the first block and continues 
with each subsequent logical record. 

The information supplied by the user in the Record Identification 
field is preserved by CICS for use when GETNEXT requests are issued. 
The Record Identification field is used by CICS during subsequent 
GETNEXT operations and should not be released by the application 
programmer. CICS places the identification of each record into this 
field as the record is retrieved in response to a GETNEXT request. 

This feedback, placed into the Record Identification field by CICS, 
is always in a form which completely identifies each record. (Refer 
to the section "Data Base Considerations" for further information 
concerning the Record Identification field.) For example, assume a 
browse operation is to start with the first logical record of a blocked, 
keyed DAM data set. Before issuing the DFHFC TYPE=SETL macro 
instruction, the user should place the TTR (assuming that is the 
addressing method) of the first block into the Record Identification 
field. After executing each DFHFC TYPE=GETNEXT macro instruction, 
CICS places the complete logical record identification into the Record 
Identification field. After the first GETNEXT, the Record 
Identification field might contain: 

C0C001BLOCK1REC1 

where "000001" represents the TTR value, "B10CK1" represents the block 
key, and "REC1" represents the record key. 

SEGSEI: This operand is used to specify the symbolic name of the 
default segment set tc te retrieved during a browse operation involving 
segmented records. This segment set is used automatically by CICS 
if the user fails to specify a segment set name on subsequent GETNEXT 
service requests. The segment set identified by a SETL macro 
instruction is always used as the default segment set throughout a 
browse operation unless altered by a RESETL macro instruction. The 
symbolic name must have been previously defined in the associated 
Segment Control section of the File Control Table (FCT) . 

SEGSET=YES is u-sed if the application programmer has dynamically 
placed the symbolic name of the segment set in the TCA field labeled 
TCAFCSI prior to issuing the DFHFC TYPE=SETI macro instruction. 

SEGSET=ALL is used if the application programmer wishes all segments 
of a record returned in an unpacked and aligned format. 

If the SEGSET operand is omitted, and the data set contains segmented 
records, the logical record is returned in its packed format. 

RETMETH: Applicable only tc blocked EDAM data sets, the RETMETH operand 
is used to specify the format of the logical record identification 
that is placed in the user's Record Identification field by CICS each 
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time the next logical record is retrieved in a browse operation. If 
RETMITH=RELREC is specified, the one-byte binary relative record number 
is provided. If RETMETH=KEY is specified, the logical record key is 
provided; however, the records must have embedded keys. 

For example, if a user is browsing a blocked EDAM data set (non- 
keyed) and the second logical record from the second physical block 
en the third relative track was just read in response to a GETNEXT 
reguest, the Record Identification Field would contain: 

X«0CC20201» 

upon return to the user, where "0002" represents the track, "02" 
represents the block, and "01" represents the logical record within 
the block. 

The following is an example of the coding reguired to initiate a 
fcrewse operation. 



2QL Assembler language; 

FWACEAR EQU 7 

COPY DFHFWADS 

RECORD DS 0CI350 



ASSIGN BASE REGISTEB FOB FWA 
DEFINE CONTROL SECTION OF FWA 
BECORD LAYOUT 



CSECT 



START 



KEY 



ERROR 



DFHFC 


TYPE=SETL # 




DA1ASET=MASTER, 




BDIEADR=KEY, 




NCTCPEN=EBROR 


L 


FWACEAR, TCAECAA 


DS 


0CL8 


DC 


CL5»JONES« 


DC 


XLS^O 1 


DS 


OH 



INITIATE BROWSE 



CHECK FOR ERRORS 



INITIAL KEY DESIGNATION 

PARTIAL KEY 

PADDING 

ENTRY TO ERROR ROUTINE 



121 5JS COJOL: 

02 FWACEAB PICTUBE S9(8) OSAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA. 



01 DFHTCAES COPY EFHTCADS. 

02 KEY PICTURE X(8) . 
01 DFHFWADS COPY DFHFWADS. 

02 RECCED PICTURE X(350). 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA. 
NOTE DEFINE KEY FIELD IN TWA. 
NOTE COPY SYMEOLIC STRG DEFN FOR FWA. 
NOTE DEFINE RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACEAR, 



NOTE ESTAELISH TCA ADDRESSABILITY. 
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MOVE 


•JONES' TC KEY. 


START. 






DFHFC TYPE=SETL, 




DATASET=MASTER, 




RDIEaDR=KEY, 




NCTCIEN=EBROR 


MOVE 


TC3FCAA TO FWACEAB. 



INITIATE BROWSE 



CHECK FOR ERRORS 



ERROR. 



For PL/I: 

^INCLUDE DFHTCADS; 
02 KEY CHAR (8) ; 



/♦COPY SYMBOLIC STRG DEFN FOR TCA*/ 



^INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/♦COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE RECORD LAYOUT IN FWA*/ 



KEY=« JONES' ; 

START: 

DFHFC TYPE=SETL, 

DATASET=MASTER, 

REIEADR=KEY, 

NCTOPEN-EBROR 

FWACBAR=TCAFCSA; 



INITIATE BROWSE 



CHECK FOR ERRORS 



ERROR: 



RETRIEVE NEXT SEQUENTIAL RECORD (GETNEXT) 

Once the application programmer has issued a DFHFC TYPE=SETL macro 
instruction to initiate a browse operation, he may request the next 
(or first) sequential record by issuing the 

DFHFC TYPE=GETNEXT, 

SEGSET=symbolic name, YES, ALL, 
NCRESP=symbolic address, 
SEGIDER=symbclic address, 
INVREQ=symtolic address, 
IOEBROR=syrabclic address, 
NOTCPEN=symbclic address, 
ENDFILE=symtclic address 

macro instruction. When the first GETNEXT reguest is issued following 
a SETL request for an ISAM data set, CICS acguires the first logical 
record with a key equal tc cr higher than the key presented by a 
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previous SETL; for a DAM data set, CICS acquires the first logical 
record specified by the user. When initiating a browse operation en 
a EAM data set, the user must provide a specific record reference. 
Each subsequent GETNEXT request, whether for an ISAM or DAM data set, 
causes CICS to acquire the next logical record in sequence. 

Before issuing the DFHFC TYPE=GETNEXT macro instruction, the 
application programmer must place the address of the FWA associated 
with the particular operation in the TCA field labeled TCAFCAA. If 
the application program has initiated multiple browse operations, it 
irust keep track of the FWA associated with each operation ana refer 
to a specific FWA when requiring services related to that browse. 

CICS performs the following services in response to a DFHFC 
TYPE=GETNEXT macro instruction: 

1. Retrieves the next sequential record and places it in the FWA 
specified by the user at TCAFCAA. 

2. Places the record identification (Key, block identification, 
etc.) of the record just retrieved into the users Record 
Identification field which was specified in the DFHFC TYPE=SETL 
request. (Refer to the discussion of Record Identification 
field feedback under the RDIDADR operand.) If the user wishes 
to issue a random "read for update" on the record just returned, 
he need only specify the address of the Record Identification 
field in his GET request. 

In addition, CICS can perform the following services, depending 
en the operands included in the DFHFC TYPE=GETNEXT macro instruction. 

1. Present the user with the segments as specified in the GETNEXT 
reguest. 

2. Present the user with the segments as specified in the SETL 
request if no segment set is specified with the GETNEXT request. 

3. If the FWA is not large enough to process a segment set specified 
in the GETNEXT request, dispose of the old FWA and acquire a 

new one large enough to process the new request. 

A discussion of the operands that can be included in the DFHFC 
TYPE=GETNEXT macro instruction follows. (The keywords used to access 
user-written exception handling routines are discussed in the section 
"Test Response to a Request for File Services".) 

3EGSET: This operand is used to specify the symbolic name of the 
segment set which is to be retrieved from the next sequential record. 
If this operand is not included in the DFHFC TYPE=GETNEXT macro 
instruction, CICS will use the default segment set name that may have 
been specified in the DFHFC TYPE=SETL macro instruction. 

If this operand is omitted on a GETNEXT operation and if SEGSET 
was specified in the DFHFC TYPE=SET1 macro instruction, the eight- 
character default segment identification, as specified in the SETL 
macro instruction, is returned at TCAFCSI upon normal completion of 
the GETNEXT. 

SEGSET=YES is used if the application programmer has dynamically 
placed the segment set naice in the TCA field labeled TCAFCSI prior 
to issuing the DFHFC IYFE=GETNEXT macro instruction. 

SEGSET=AL1 is specified if the application programmer wishes all 
segments returned in an unpacked and aligned format. 
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The following is an example of the coding necessary to retrieve 
the next sequential record in a browse operation using segmented 
records. 



12L Assembler language: 

COPY DFHTCADS 

KEY DS 8X 

FWACBAR EQU 7 

COPY DFHFWADS 

JECORDA DS CCL350 



COPY TCA SYMBOLIC STRG DEFN 

DEFINE KEY FIELD IN TWA 

ASSIGN FWA EASE REGISTER 

DEFINE CICS CONTROL SECTION OF FWA 

DEFINE RECOBD LAYOUT IN FWA. 



CSECT 

MVC KEY (8) ^SX'OO* 
INITIAL DFEFC TYPE=SETL r 

DATASET=MASTER, 

SEGSET=A, 

RDIDADR=KEY 



START AT BEGINNING OF DATA SET 
INITIATE BROWSE 

SET DEFAULT SEGMENT SET 



L FWACBAR, TCAFCAA ESTABLISH FWA BASF REGISTER 



ST FWACBAR, TCAICAA 

PFEFC TYPE=GETNEXT GET NEXT SEQUENTIAL RECORD 



ST FWACEAR, TCAFCAA 

DFEFC TYPF=GETNEXT, GET NEXT RECORD 
SEGSET=B WITH SEGMENT B 



for ANS COBOL: 

02 FWACBAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA. 

CI DFHTCADS COPY DFRTCAD5. NOTE COPY SYMBOLIC STRG DEFN FOR TCA. 

02 KEY PICTURE S9 ( 18) CSAGE IS COMPUTATIONAL. 

NOTE DEFINE KEY FIELD IN TWA. 



C1 DEHFWADS COPY DFHFWADS. 
02 RECCED PICTURE X(350) 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA. 
NOTE DEFINE RECORD LAYOUT IN FWA. 



PROCEDURE DIVISION. 

MOVE CSACDTA TO TCACEAR, 



NOTE ESTAELISH TCA ADDRESSABILITY. 



MOVE TO KEY, 



NOTE START AT BEGINNING OF DATA SET. 



DFHFC TYPE=SETL 



INITIALIZE BROWSE 
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DATASET=M*STER, 
SEGSET=A, 
REIEADR=KEY 
MOVE TCAFCAA TC FWACEAR. 



SET DEFAULT SEGMENT SET 

BOTE ESTABLISH FWA ADDRESSABILITY. 



MOVE EWACEAE TO TCAFCAA. 

DEHFC TYPI=GETNEXT 



GET NEXT SEQUENTIAL RECORD. 



MOVE FWACEAR TO TCAFCAA. 
DFHFC TYPE=GETNEXT, 
SEGSET=B 



GET NEXT RECORD 
WITH SEGMENT 3 



For PL/I: 

%INCLUDE CFHTCADS; 

02 KEY BINARY FIXED(8,0); 



/♦COPY SYMBCLIC STRG DSFN FOR TCA*/ 
/*DEFINE KEY FIELD IN TWA*/ 



^INCLUDE DFHFWADS; 

02 RECORD CHAR (350) ; 



/*COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE RECOED LAYOUT IN FWA*/ 



KEY=0; 



/♦START AT BEGINNING OF DATA SET*/ 



DFHFC TYPE=SETL, 

DATASEI=MASTEE, 
SEGSET=A, 
REIEADR=KEY 
FWACBAR=TCAFCAA; 



INITIALIZE BROWSE 

SET DEFAULT SEGMENT SET 

/♦ESTABLISH FWA ADDRESSABILITY*/ 



TCAFCAA=FWACBAR; 

DFHFC TYPE=GETNEXT 



GET NEXT SEQUENTIAL RECORD 



TCAFCAA=FWACEAR; 

DFHFC TYPE=GETNEXT, 
SEGSET=B 



GET NEXT RECORD 
WITH SEGMENT B 



TERMINATE SEQUENTIAL RETRIEVAL (ESETL) 

The application programmer may terminate a browse operation by 
issuing the 

DFHFC TYPE=ESETL r 

INVREQ=symbclic address 
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macro instruction. Before the macro is issued, the programmer must 
ensure that the TCA field labeled TCAECAA contains the address of the 
"File Work Area (FWA) associated with the trcwse operation he wishes 
to terminate. In response to an ESETL request, CICS will release all 
I/O and work areas associated with the browse operation. 

The following is an example of the coding necessary to terminate 
twc concurrent browse operations. 



1QI Assembler lanc[ua<je: 

COPY DFHTCADS 

FWACELL1 DS A 
* 

FWACEIL2 DS A 

FWACBAR EQU 7 

COPY DFHFWADS 

RECORD DS 0CI350 



COPY TCA SYMBOLIC STRG DEFN 
CONTAINS ADDR OF FWA USED 
FOR FIRST BBOWSE OPERATION 
CONTAINS ADDR OF FWA USED 
FOR SECOND BROWSE OPERATION 
ASSIGN FWA BASE BEGISTER 
DIFINE FWA SYMBOLIC STORAGE DEFN 
DEFINE BECORD 



CSECT 



MVC TCAFCAA, FWACE1L1 
DFHFC TYPE=ESETL 
MVC TCAECAA, FCACEIL2 
DFHFC TYPE=ESETL 



MOVE BBOWSE 1 FWA ADDR TO TCA 

ISSUE ESETL MACRO INSTRUCTION 

MOVE BROWSE 2 FWA ADDR TO TCA 

ISSUE ESETL MACRO INSTRUCTION 



I°I MS CCECL: 

02 FWACBAB PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR EWA. 



C1 DFHTCADS COPY DFHTCADS. 
02 FWACELL1 PICTURE S9 (8) 
02 FWACEII2 PICTURE S9 (8) 

01 DFHFWAES COPY BFHFWADS. 
02 BECCBD PICTURE X(350). 



NOTE COPY SYMBOLIC STRG DEFN FOR TCA, 
USAGE IS COMPUTATIONAL. 
USAGE IS COMPUTATIONAL. 

NOTE COPY SYMBOLIC STRG DEFN FOR FWA. 

NOTE DEFINE BECORD LAYOUT IN FWA. 



MOVE FWACELL1 TO TCAFCAA. 
DFHFC TYPE=ESETL 



NOTE PBEPARE TO END FIRST BROWSE. 
TERMINATE FIRST EROWSE. 



MOVE FWACEIL2 TO TCAFCAA. 
DFHFC TYPE=ESETL 



NOTE PBEPARE TO END 2ND BROWSE. 
TERMINATE SECOND BROWSE. 



lor PL/I: 

^INCLUDE DFHTCADS; 

02 FWACEII1 POINTER; 
02 FWACELL2 POINTER; 



/*COPY SYMBOLIC STRG DEFN FOR TCA*/ 



^INCLUDE DFHFWADS; 



/*COPY SYMBOLIC STRG DEFN FOR FWA*/ 
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02 RECORD CHAR (350) ; 



/*DEFIME RECORD LAYOUT IN FWA*/ 



TCAFCAA=PWACEIL1; 

DFHFC TYPE=ESETL 
TCAFCAA=FWACELL2; 

DFF.FC TYPE=ESETL 



/*MOVE BROWSE1 FWA ADDR TO TCA*/ 
/♦MOVE BROWSE2 FWA ADDE TO TCA*/ 



RESET SEQUENTIAL RETRIEVAL (RESET!) 

Once a browse operation has been initiated with a SETL request, 
the application programmer may, at any time prior to issuing the ESETL 
request, reset the search arqument to seme record ether than the next 
sequential record. He can accomplish this by issuing the 

DFEFC TYPE=RESETL, * 

SEGSET=symbolic name, YES, ALL, * 

NCRESP=symbclic address, * 
SEGIDER=symbclic address 

macro instruction. Prior to issuing the request, the application 
programmer should place the address of the appropriate FWA into the 
TCA field labeled TCAFCAA and place the new record identification in 
the Record Identification field specified through the RDIDADR operand 
in the original SETL request. 

The use of the RESETL macro instruction allows the application 
programmer to avoid issuing an ESETL request followed by another SETL 
request, and causes CICS to use the same I/O and work area. Upon 
return from the RESETL reguest, the TCA field labeled TCAFCAA contains 
the address of a new FWA which the user can use for the browse 
operation. 

The RESETL request allows the user to "skip" throuqh his data set 
in a browse operation with the least possible overhead. 

SEGSET: This operand allows the user to replace the default segment 
set identification specified at SETL. If this operand is omitted, 
the SEGSET specified in the last SETL or RESETL for this browse 
operation is used. 

SEGSET=YES is used if the application programmer has dynamically 
placed the symbolic name of the segment set in the TCA field labeled 
TCAFCSI prior to issuing the DFHFC TYPE=RESETL macro instruction. 

SEGSET=ALL is used if the application programmer wishes all segments 
of a record returned in an unpacked and aligned format. 

The following is an example of the coding necessary to reset the 
search argument and the default segment set for a browse operation. 



151 Assembler lanauacje: 

COPY DFHTCADS 

KEY DS D 

FWACBAR EQU 7 

COPY DFHFWADS 

FEC0RD1 DS 0CL350 



COPY TCA SYMBOLIC STRG DEFN 
DEFINE KEY FIELD IN TWA 
ASSIGN FWA EASE REGISTER 
COPY FWA DSECT 
DEFINE RECORD WITH SEGSET A 
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ORG 
l?ECORD2 DS 



RECORD1 
OCL250 



DEFINE RECORD WITH SEGSET B 



CSECT 

MVC KEY (8) ,=8X'00* 

DFEFC TYPE-SETL, 

DATASET=MASTER, 

RDIEADR=KEY, 

SEGSET-A 

L FWACEAR,TCAICAA 



INITIALIZE KEY FIELD 

ISSUE INITIAL SETL MACRO 

FOB DATASET "MASTER" 

INITIAL SEARCH ARG=0 

FOE SEGSET=A 

ESTABLISH ADDRESSABILITY TO FWA 



ST FWACEAR,TCAECAA 
MVC KEY (8) ,=CL8«SMITH» 
DFEFC TYPE=RESETL, 

SEGSET=B 
L FWACEAR, TCAFCAA 



STORE FWA ADDR IN TCA 

ESTABLISH NEW SEARCH ARGUMENT 

ISSUE RESETL MACRO * 

NEW SEGSET ID 

ESTABLISH ADDRESSABILITY TO FWA 



lor ANS CCEOL: 

02 FWACBAR PICTURE S9 (8> USAGE IS COMPUTATIONAL. 

NOTE DEFINE BASE REGISTER FOR FWA. 

01 DFHTCADS COPY DFHTCADS. NOTE COPY SYMBOLIC STRG DEFN FOR TCA. 

02 KEY PICTURE S9(18) OSAGE IS COMPUTATIONAL. 

NOTE DEFINE KEY FIELD IN TWA. 
02 FILLER REDEFINES KEY. 
03 KEYC PICTURE X (8) . 



01 DFHFWAES COPY DFHFWADS. 

02 EECOED1 PICTURE X (350) . 



NOTE COPY SYMBOLIC STRG DEFN FOR FWA, 
NOTE DEFINE HECORD WITH SEGSET A. 



01 DFEFWA REEEFINES DFHFWADS. 
02 CICSPARI PICTURE X {*) . 
02 EECOED2 PICTURE X (250) . 



NOTE CREATE STRG DEFN FOR FWA. 
NOTE PLACE LENGTH OF FWA HERE. 
NOTE DEFINE RECCED WITH SEGSET B, 



MOVE TO KEY. 

DFHFC TYPE=SETL, 

DAIASET=MASTER, 

RBIEADR=KEY, 

SEGSET=A 

MOVE TCAFCAA TO FWACEAR. 



ISSUE INITIAL SETL MACEO INSTR * 
FOR DATASET "MASTER" * 

INITIAL SEARCH ARG=0 * 

FOR SEGSET=A 
NOTE ESTABLISH ADDRESSABILITY TO FWA. 



MOVE FWACBAE TO TCAFCAA. 
MOVE "SMITH 1 TO KEYC. 
DFHFC TYPE=RESETL, 

SEGSET=B 
MOVE TCAFCAA TO FWACBAR. 



NOTE STORE FWA ADDEESS IN TCA. 

NOTE ESTABLISH NEW SEARCH ARGUMENT. 

ISSUE RESETL MACRO INSTRUCTION * 

NEW SEGSET ID 

NOTE ESTABLISH ADDRESSABILITY TO FWA. 
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19E SLZI- 



^INCLUDE DFHTCADS; 

02 KEY EINARY FIXED (8,0) ; 
EECLARE 01 DFHXTCA EASED (TCACBAR) , 

02 FILL CHAE (*) , 

02 KEYC CHAE (8) ; 



/♦COPY SYMBOLIC STEG DEFN FOR TCA*/ 
/*DEFINE KEY AS BINARY*/ 

/*PLACF LENGTH OF TCA HERE*/ 
/♦DEFINE KEY AS CHARACTER*/ 



3INCLUDI EFHFWADS; 

02 BECCBD1 CHAR (350) ; 
EECLARE 01 DFHXFWA EASED (FWACBAR) , 

02 FILL CHAR (*) , 

02 EECORD2 CHAP (250) ; 



/♦COPY SYMBOLIC STRG DEFN FOR FWA*/ 
/♦DEFINE BECORD WITH SEGSET A*/ 

/♦PLACE LENGTH OF FWA HERE*/ 
/♦DEFINE BECORD WITH SEGSET B*/ 



KEY=0; 

DFBFC TYPE=SETL, 

DATASET-MASTER, 

REIEADR=KEY,- 

SEGSET=A 

F**ACBAR=TCAFCAA; 



/*SET KEY VALUE TO ZERO*/ 

ISSUE INITIAL SETL MACRO INSTR * 

FOB DATA SET "MASTER" * 

INITIAL SEARCH ARG EQUALS ZERO * 

FOB SEGSET A 

/♦ESTABLISH ADDRESSABILITY FOR FWA*/ 



TCAFCAA=FWACBAR; 
KEYC=«SMITH»; 

DFBFC TYPF=RESETL, 
SEGSET=B 
FWACBAR=TCAFCAA; 



/♦STORE FWA ADDR IN TCA*/ 
/♦ESTABLISH NEW SEARCH ARGUMENT*/ 
ISSUE RESETL MACRO INSTRUCTION * 
NEW SEGSET ID 
/♦ESTABLISH ADDRESSABILITY TO FWA*/ 



1EST BESFCNSE TO A REQUEST FOR FILE SERVICES (CHECK) 

One of the ways the application programmer can test the response 
tc a request for file services is by issuing the 



DFHFC 1YPE=CH 
NCBESP= 
ESIDER= 
SEGIDER 
NOTFND= 
EUPREC= 
INVREQ 
IOERBOR 
DUPDS=s 
NOSPACE 
NCTCEEN 
FNDFILE 



ECK, 

symbolic 

symtolic 

=symtclic 

symbolic 

symtolic 

symbolic 

=symbclic 

ymbclic a 

=symbclic 

=symbclic 

=symbclic 



address, 
address, 

address, 
address, 
address, 
address, 

address, 
d dress, 
address, 
address, 
address 



macro instruction, which provides for the testing of response codes 
and the routing of control to the appropriate user-written exception 
handling routines. This macro instruction provides an exception 
handling facility that can be used in the manner of a subroutine. 

CICS automatically places the appropriate response code in the TCA 
at TCAFCTR (TCAFCRC if the language is ANS COBOL) after completion 
of the file service requested. The application programmer must specify 
the entry labels (symtolic addresses) he requires to access the 
appropriate exception handling routines previously supplied by the 
user. 
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if the application programmer does not . use the DFHFC TYPE=CHECK 
macro instruction, he can specify the entry labels in either of two 
other ways: (1) by including the entry labels in operands of any other 
DFHFC macro instruction, or (2) by coding instructions immediately 
following the DFHFC macro instruction that examine the response code 
provided by CICS at TCAFCTR (TCAFCRC if the language is ANS COBOL) and 
transfer control to the appropriate routine. 

The response codes are as follows: 



CONDITION 


ASSEMBLER 


ANS COBOL 


PL^I 


NORESP 


X'OO' 


12-0-1-8-9 


00000000 


DSIDER 


X'01' 


12-1-9 


00000001 


SEGIDER 


X«04» 


12-4-9 


00000100 


INVREQ 


X'08« 


12-8-9 


00001000 


DUPDS 


X'OA' 


12-2-8-9 


00001010 


NOTOPEN 


X'OC 


12-4-8-9 


00001100 


ENDFILE 


X'OF' 


12-7-8-9 


00001111 


IOERROR 


X'80 1 


12-0-1-8 


10000000 


NOTFND 


X«81» 


12-0-1 


10000001 


DUPREC 


X'82' 


12-0-2 


10000010 


NOSPACE 


X'83' 


12-0-3 


10000011 



If the DFHFC TYPE=CHECK macro instruction is used by the application 
programmer, it normally follows another DFHFC macro instruction. The 
applicable keywords are NORESP, DSIDER, SEGIDER, NOTFND, DUPREC, INVREQ, 
IOERROR, DUPDS, NOSPACE, NOTOPEN, and ENDFILE. 

Notej. When an exception condition occurs (for example, NOTFND, IOERROR, 
or DUPREC) , the FIOA is retained; the FIOA contains the address 
of the FCT data set entry that produced the exception condition. 
The FIOA address is returned to the user at TCAFCAA. Before 
issuing other File Control requests, the user should free the 
storage occupied by the FIOA through use of the DFHFC 
TYPE=RELEASE macro instruction. 

If the application programmer does not check for a particular 
response to his service request, and if that exception condition occurs, 
program flow proceeds to the next sequential instruction. 

A discussion of the operands that can be used to test the response 
to a request for file services follows. 

NORESP: Specifies the entry label of the user-written routine to which 
control is to be passed in the event no errors occur on a file 
operation. NORESP signifies "normal response" rather than "no 
response". 

DSIDER: Specifies the entry label of the user-written routine to which 
control is to be passed if the data set specified at TCAFCDI cannot be 
located in the File Control Table. DSIDER signifies "data set 
identification error". 

SEGIDER: Specifies the entry label of the user-written routine to 
which control is to be passed if the segment set specified at TCAFCSI 
cannot be located in the File Control Table. SEGIDER signifies "segment 
set identification error". 
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NOTFND: Specifies the entry label of the user-written routine to which 
control is to be passed in the event of an unsuccessful retrieval of 
a record based on the search argument provided (key or block reference) . 
NOTFND signifies a "record not found" situation. 

DUPREC: Specifies the entry label of the user-written routine to which 
control is to be passed in the event an attempt is made to add a record 
to the data set in which one already exists with that key. DUPREC 
signifies "duplicate record". 

INVREQ: Specifies the entry label of the user-written routine to which 
control is to be passed in the event a file operation is attempted that 
is not provided for (or allowed) according to the data set entry 
specifications in the FCT. INVREQ signifies "invalid reguest". The 
address of the appropriate File Control Table entry is returned at 
TCAFCAA. 

IOERROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event an unusual event occurs 
during a file operation. When an I/O event error code is not covered 
by one of the CICS error classes (for example, NOSPACE, NOTFND) , it is 
considered an I/O error. The user's routine may check the actual error 
codes in the FIOA (FCFIOBEX in the case of DAM or BDAM, FCFIOEX in the 
case of ISAM) , the address of which is returned in the TCA field labeled 
TCAFCAA. Since these error codes are access method and operating system 
dependent, the user should be aware that checking these codes in his 
application programs would have a limiting effect on migrating those 
application programs from CICS/DOS to CICS/OS, if this were ever 
desired. 

DUPDS: Specifies the entry label of the user-written routine to which 
control is to be passed in the event the record just retrieved on an 
indirect access is from the duplicate data set rather than from the 
prime (master) data set. The duplicate record is processed by the 
user-written routine rather than allowing the record to be processed 
by main line code as a prime data set record. DUPDS signifies 
"duplicate data set". 

NOSPACE: Specifies the entry label of the user-written routine to 
which control is to be passed in the event no direct access space is 
available for adding records to a data set. When this condition occurs, 
the original user record is returned in a File Work Area (FWA) the 
address of which is at TCAFCAA. The main storage location of this FWA 
may be different from that for the FWA acquired in response to the 
DFHFC TYPE=PUT macro instruction (which was issued to add the record) . 
This error code is not applicable when adding records to DAM non-keyed 
data sets. 

NOTOPEN: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the requested data set is 
not open. This error condition can occur after any file service request 
except RELEASE, ESETL, and RESETL because data base data sets can be 
dynamically closed at any time without regard to outstanding activity 
on the data set. 

ENDFILE: Specifies the entry label of the user-written routine to 
which control is to be passed in the event an end-of-file condition 
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is detected during the sequential retrieval (browse) of records from 
a data set. This condition occurs only after a GETNEXT request. 

The following are examples of the coding required to examine the 
response code provided by CICS at TCAFCTR (TCAFCBC if the language 
is ANS COBOL) and transfer control to the appropriate user-written 
error handling routine. 

Eor Assembler lan.guac[e. : 



DFHFC 


TYPE=GET, 




DA1ASE1=MASTER, 




BDIEAEB=KEY 


CLI 


TCAFCTR, X'OO 1 


BE 


GOOD 


CLI 


TCAECTE,X , 30« 


BE 


EBBOB 


CLI 


TCAFCTR, X'Oa 1 


BE 


EBBOR 



GOOD DS OH 



EBBOB DS OH 

DFHPC IYPE=ABEND 



For AJS CCECL: 

DFHFC TYPE=GET, * 

DA1ASE1=MASTEB', * 

BDIEADB=KEY 

IF TCAFCBC=» » THEN GO TO GOOD. 

IF TCAICBC=» ' THEN GO TO EBBOR. 

IF TCAFCBC=» ' THEN GO TO EBBOB. 



GOOD. 



EBBOB. 



DFHPC TYPE=ABIND 



where the value specified within single quotes is a multipunch code 
for the required hexadecimal value. For example, a hexadecimal 00 
has a multipunch code of 12-0-1-8-9. 



191 21/1'- 



DFHFC TYPE=GET, * 

DATASET=MASTER, * 

RDIDADR=KEY 

IF TCAECTR='0CC0OOOO , B THEN GO TO GOOD; 

IF TCAFCTR='1CCC0000 , B THEN GO TO EBBOR; 

IF TCAFCTR='0000 1000»B THEN GO TO EBBOR; 
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GCOD: 



EFBOR: 

DFHPC TYPE=ABEND 



JJiJSIJNT DATA SERVICES 

Transient Data Management provides, through Transient Data Control, 
a generalized queuing facility where data can be queued (stored) for 
subsequent internal or external processing. Selected units of 
information, as specified by the application programmer, can be routed 
to or from predefined symbolic destinations, either intrapartition 
or extrapartition. 

Intrapartition destinations are gueues of data on direct access 
devices developed for input to cne or more programs running 
asynchronously (concurrently) as separate tasks; they are internal 
to the CICS partition/region. Data directed to or from these internal 
destinations is called intrapartition data and may consist only of 
variable-length records. Intrapartition destinations can be associated 
with (1) a terminal (to accomplish message switching or to route data 
to a terminal other ^han the originating terminal) , (2) an output data 
set, or (3) an application program under the control of CICS. 

The intrapartition gueue is reusable. An option permits the user 
to indicate, by symbolic destinaticn, whether Transient Data space 
management is to control the reuse of tracks associated with a 
particular destination identification (DESTID) , or whether the releasing 
of track space is to be controlled through the Transient Data PURGE 
macro facility. Note that if Transient Data space management is not 
used, intrapartition queues continue to grow, irrespective of whether 
the data has been read, until the user purges them. 

Extrapartition destinations are queues (data sets) that are external 
to the CICS partition/region, residing on tape or direct access devices. 
Data directed to or from these external destinations is called 
extrapartition data and may consist of sequential records that are 
fixed or variable length, blocked or unblocked. The record format 
specification is described in the Destination Control Table in the 
System Prograjmerjs Reference Manual. 

Intrapartition and extrapartition destinations can be used as 
indirect destinations which are symbolic references to still other 
destinations. This facility provides some flexibility in program 
maintenance in that an installation can be changed, giving a destination 
a new symbolic name, without recompiling existing programs. These 
programs can be allowed to route data to the previously existing 
symbolic name; however, the previously existing symbolic name is now 
an indirect destination that refers to the new symbolic name. 

Requests for transient data services are communicated to Transient 
Data Control via CICS macro instructions. Transient Data Control then 
executes as a service program, at the priority of the requesting 
program, under control of the requesting program 1 s TCA, saving and 
restoring registers from this TCA. After the requested transient data 
service has been provided (or attempted) , control is returned to the 
next executable instruction in the requesting program. Upon return 
to the requesting program, tests can be made and control routed to 
various user-written error handling routines based on the outcome of 
the requested transient data service. 
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The Transient Data Management macro instruction (DFHTD) is used 
to request any of the following services: 

1." Acquire data from a predefined symbolic source which references 
a data set, a program, or a terminal. 

2. Direct data to a predefined symbolic destination which references 
a data set, a program, or a terminal. 

3. Control the processing of extrapartition data sets. 

4. Check the response to a request for transient data services. 

CICS routes a variety of messages generated by CICS programs or 
tasks to Transient Data Control. For example. Terminal Control detects 
a line or teririnal problem (not related to a user-provided task) and 
routes control to the CICS Terminal Abnormal Condition program 
(DFHTACP) . DFHTACP then generates a message to symbolic destination 
CSTL (terminal log) and/or to symbolic destination CSMT (master 
terminal) . 

Destinations must have been previously established in the Destination 
Control Table (ECT) for all user and CICS destinations. Lack of a 
destination definition results in the loss of data sent to these 
destinations. 

For intrapartition destinations, CICS provides the option of 
automatic task initiation. Automatic task initiation is accomplished 
by setting a nonzero trigger level for a particular destination. When 
the number of entries (PUT's from one or more programs) in the queue 
(destination) reaches a specified level, the transaction is 
automatically initiated and a program given control to process the 
data in that queue. The program that has been automatically initiated 
must issue repetitive GET's to deplete the queue. 

Once the queue has been depleted, a new automatic task initiation 
cycle begins. That is, a new task is scheduled for initiation when 
the specified trigger level is again reached, whether or not execution 
of the prior task has terminated. 

If an automatically initiated task does not deplete the queue, 
access to the queue is not prevented. If the task is normally or 
abnormally terminated before the queue is emptied, and if the 
destination is a terminal, the same task is reinitiated regardless 
of the trigger level. However, if the destination is a data set (file) , 
the task is not reinitiated ujitil the specified trigger level is 
reached. If the trigger level of a queue is zero, no task is 
automatically initiated. 

The following operands can be included in the DFHTD macro 
instructicn: 

DFHTD TYPE=PUT, * 

DESTlD=syrabolic name, * 

TDADDB=symbolic address, * 

NOBESP=symbolic address, * 

IDE5B0E=syrabclic address, - * 

IOEBBOE=symtclic address, * 

NOTOEEN=syrabclic address, * 
NOSPACE=symfcclic address 
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EFHTD TYPE=GET, * 

DESIID=symbolic name, * 

N0EESP=3ymfcclic address, * 

CUEZEEO=symbclic address, * 

IDiHEOB=symtclic address, * 

IOEBEOB=symbclic address, * 
NOTOEEN=synibclic address 

EFHTD TYFE-FEOV, * 

DESTID=symbolic name, * 

NOEESP=symbolic address, * 

IDEEEOR=symbclic address, * 
NOTOEEN=syinfcclic address 

EFHTD TYPE=PUBGE, * 

DESTID=symbolic name, * 

IDEBBOB=symbclic address, * 
NOEESP=symbolic address 

EFHTD TYPI=CHECK, * 

NGRESP=symbolic address, * 

QUEZEEO=symbclic address, * 

IEEBBOR=symbclic address, * 

IOEBBOR=symbclic address, * 

NOTOPEN=symbclic address, * 
NOSPACE=symbclic address 

EISPCSE OF DATA (PDT) 

The application programmer can direct transient data to a predefined 
symbolic destination by issuing the 

DFHTE TYPE=PUT, * 

DES'IID=symbolic name, * 

TBAEER=symbclic address, * 

NOBESP=symbclic address, * 

IDEBEOR=symbclic address, * 

IOEEBOE=symbclic address, * 

NCTCPEN=symfcclic address, * 
NOSPACE=symbclic address 

macro instruction. Destinations are intrapartition if associated with 
a facility allocated to the CICS partition/region and extrapartition 
if the data is directed to some destination that is external to the 
CICS partition/region. If the data is intrapartition, a copy of the 
TDOA symbclic storage definition (DFHTDOA) should be included and all 
references to the output area should be made via a register (TDOABAE) 
which points to the beginning of the area. 

If the data is variable length, whether intrapartition or 
extrapartition, tfce first four bytes of the data (LLbb) contain the 
data length, where LL is a two-byte binary length field (the value 
of which includes the length of the data plus the four bytes for the 
length field) and bb is recommended to be a two-byte field of binary 
zeros. 

The application programmer must specify the parameters he reguires 
to dispose of transient data. He can do this in either of two ways: 
(1) by including the parameters in operands of the DFHTD TYPE=PDT macro 
instruction, or (2) by coding instructions, prior to issuing the DFHTD 
TYPE=PUT macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in operands of 
the EFHTD TYPE=PDT macro instruction, the applicable keywords are 
DESTID and TDADDB. 
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A discussion of the operands that can ba included in the DFHTD 
1YPE=PUT macro instruction follows. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Request for Transient Data Services".) 

DESTID: Specifies the symbolic destination name (which is the name 
cf an entry in the BCT) tc which the data is to be routed and queued. 
The destination name can be coded in the macro instruction or 
dynamically loaded in the TCA at location TCATDDI. 

TEADDR: Specifies the address of the data to be written. This can 
be provided by coding the symbolic name of the area in the macro 
instruction or by dynamically loading the address of the area in the 
TCA at location TCATDAA. Transient Data Control does not release this 
area after the output of the data. The address points to the first 
four bytes of the output area which, for variable length records and 
intrapartition data, must contain the length of the record. This 
length includes both the length of the data and the length field (of 
the form LLbb) . 

The following are examples of the coding required to write data 
to a predefined symbolic destination. 

IQI Assembler lanquacje: 
TDOABAR 

CRTA 



MVC TDOAVRI, LENGTH 
HVC EATA, MESSAGE 
MVC TCATDDI, =C»CSML« 
EFHTD TYPE=PUT, 

TDADDR=TDOAVBL 



EQU 


7 


COPY 


DFHTEOA 


DS 


CL10 



Eor ANS COBOL: 



02 TDCAEAR PICTURE S9 (8) USAGE IS COMPUTATIONAL, 



MCVE LENGTH TO TEOAVRL. 
MOVE MESSAGE TO EATA. 
MOVE «CSML' TO TCATDDI. 
DFHTD 1YPE=PUT, 

inADER=TEOAVRL 
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For PL/i ; 

^INCLUDE EFHTDOA; 

2 DATA CHAB(10) ; 



TDOAVBL=LINGTH; 

EATA=MESSAGE; 

*ECATDDI= , CSML , ; 

DFHTD TYPE=POT, 

TDADDB=TDOAVBL 



ACQUIBE QUEUED DATA (GET) 

The applicatj.cn programmer can acquire transient data from a 
predefined symbolic source by coding the 

DFHTD TYFE=GET, * 

DESTID=symbolic name, * 

NOBESP=symbolic address, * 

QDEZEBO=symbclic address, * 

IDEBFOR=symbclic address, * 

IGEBECR=symbclic address, * 
NOTCPEN=symbclic address 

macro instruction. The address of the data acquired is returned in 
the TCA at TCATDAA. 

If the data is extrapartition, the address points to the first word 
of the data area. For variable-length records, the first four bytes 
of the data contain the length (LLbb) as specified for variable-length 
data sets. 

If the data is intrapartition, the address of the data acquired 
points to a CICS input area defined by DFHTDIA. The field TDIAIRL 
contains the length (data length plus the length of the length field) . 
In the case of either intrapartition or extrapartition data, the data 
must be moved to be used in any other input/output operation. 

If the user issues a subsequent DFHTD TYPE=GET macro, the Transient 
Data I/O area from the previous GET will be reused, thus data to be 
saved should be moved to a user area. 

Note: The application programmer should not attempt to free storage 
acquired by the Transient Data Control program in response to 
a DFHTD TYPE=GET macro instruction. This storage is freed by 
CICS in the case of intrapartition data, or by the operating 
system in the case of extrapartition data. An attempt to free 
storage acquired for extrapartition data may result in an 
abnormal termination of CICS, since the storage area address 
returned by Transient Data Control points to storage that is 
not part of the CICS dynamic storage subpool. 

The application programmer must specify the parameters he requires 
to acquire transient data. He can do this in either of two ways: 
(1) by including the parameters in operands of the DFHTD TYPE=GET macro 
instruction, or (2) by coding instructions, f rior to issuing the DFHTD 
TYPE=GET macro instruction, that dynamically move these parameters 
to fields in the ICA. If the parameters are included in operands of 
the DFHTD TYPE=GET macro instruction, the applicable keyword is DESTID. 
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A discussion of the DESTID operand follows. (The keywords used to 
access user-written exception handling routines are discussed in the 
section "Test Response to a Request for Transient Data Services".) 

DESTID: Specifies the symbolic destination name (the name of an entry 
in the DCT) from which data is to be retrieved. The name can be 
specified in the macro instruction or by dynamically loading it in the 
TCA at location TCATDDI. 

The following are examples of the coding required to read a record 
from an intrapartition data set. 



For Assembler language; 



TDIABAR 



EQU 
COPY 



DFHTDIA 



MVC TCATDDI, =C'CSML» 

DFHTD TYPE=GET 

L TDIABAR, TCATDAA 



For ANS COBOL: 

02 TDIABAR PICTURE S9(8) USAGE IS COMPUTATIONAL. 



01 DFHTDIA COPY DFHTDIA. 



MOVE 'CSML 1 TO TCATDDI. 

DFHTD TYPE=GET 
MOVE TCATDAA TO TDIABAR 



121 PI/I: 



^INCLUDE DFHTDIA; 

2 DUMMY CHAR(1) ; 



TCATDDI='CSML' ; 
DFHTD TYPE=GET 
TDIABAR=TCATDAA; 



In the' above examples, if the record is to be read from an 
extrapartition data set, the address passed to the user at TCATDAA is 
the address of the actual data. However, since the DFHTDIA symbolic 
storage definition is being used, the address must be adjusted to point 
to the CICS control area preceding the actual data. Therefore, 
immediately following the instruction that moves the contents of TCATDAA 
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to TDIABAR, another instruction must be added. The following examples 
which apply to CICS/OS are applicable TO CICS/DOS if '40' is replaced 
by '8« . 

The examples are for variable-length records where the first byte 
of the data is actually the LLbb field. Therefore, if the retrieved 
record is fixed format, the value in the examples must be 12 and 44. 

Note! This DSECT is intended to be used for intrapartition data. The 
values are subject to change in future versions of CICS. No 
DSECTs are provided for extrapartition data. 

Z°£ Assembler language: 
SH TDIABAR, =H'40» 

For ANS COBOL: 

SUBTRACT 40 FROM TDIABAR. 

For PL/I: 

DCL TDIABAA FIXED BIN (30) BASED (TDIABAB) ; 
TDIABAB = ADDR (TDIABAR) ; 
TDIABAA=TDIABAA - 40; 

If the extrapartition data set is blocked, alignment requirements 
are the user's responsibility. The DFHTDIA DSECT assumes doubleword 
alignment for the start of the LLbb field in variable records, or for 
the start of the data if fixed records are processed. 

CONTROL THE PROCESSING OF EXTRAPARTITION DATA SETS (FEOV) 

The application programmer can create a "forced end of volume" 
situation on an extrapartition magnetic tape data set (file) by issuing 
the 

DFHTD TYPE=FEOV, * 

DESTID=symbolic name, * 

NORESP=symbolic address, * 

IDERROR=symbolic address, * 
NOTOPEN=symbolic address 

macro instruction. This macro instruction is used to cause the 
rewinding and unloading of a magnetic tape reel; the next tape reel 
must then be reloaded. 

DESTID: Specifies the symbolic address of the destination against which 
"forced end of volume" is to be applied. 

Note: This facility must be used with caution since CICS operation is 
halted until the new tape reel has been reloaded. 

For a discussion of the NORESP, IDERROR, and NOTOPEN operands, see 
the section "Test Response to a Request for Transient Data Services." 

The following are examples of the coding required to create a "forced 
end of volume" situation on an extrapartition magnetic tape data set. 
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Z°£ Assembler language: 



MVC TCATDDI,=C'CSML' 
DFHTD TYPE=FEOV 



120.1 



For ANS COBOL: 



MOVE »CSML« TO TCATDDI. 
rFHTD TYPE=FEOV 



IQI SSsZl- 



TCATBD^'CSML'; 
DFHTD TYPE=FEOV 



PURGE TRANSIENT DATA (PURGE) 

When transient data associated with a particular intra partition 
destination (queue) is nc longer needed, the application programmer 
can purge the data associated with that destination by issuing the 

DFHTD TYPE=PURGE, * 

DESTID=symbolic name, * 

IDEBROR=symbclic address, * 
NOBESP=symbclic address 

macro instruction, which causes all storage associated with the 
destination tc be freed (erased and deallocated) . 

For destinations designated as non-reusable in the Destination 
Control Table, the DFHTD TYPE=PURGE macro instruction 'must be used 
to free storage "associated with the destination. Otherwise, the storage 
remains allocated to the destination, and the data associated with 
the destination continues to grow until the allocated storage is 
entirely used or until the storage is freed via this macro instruction. 

A discussion of the DESTID operand follows. For a discussion of 
the IDERROR operand, see the section "Test Response to a Request for 
Transient Data Services". 

DESTID: Specifies the symbolic destination name (the name of an entry 
in the Destination Control Table) associated with the transient data 
to be purged. The destination name can be coded in the macro 
instruction or dynamically loaded in the TCA at location TCATDDI. 

TEST RESPONSE TO A REQUEST FOR TRANSIENT DATA SERVICES (CKECK) 

One of the ways the application programmer can test the response 
tc a reguest for transient data services is by issuing the 

DFHTD 1YPE=CHECK, * 

NORESP=symbclic address, * 

QUEZEBO=symbclic address, * 

IDEHROR=symbclic address, * 
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IOEBBOR=symbclic address, * 

NOTCPEN=symbclic address, * 

NOSPACE=symbclic address 

macro instruction, which provides for the testing of response codes 
and the routing of control to the appropriate user-written exception 
handling routines. This macro instruction provides an exception 
handling facility that can be used in the manner of a subroutine. 

CICS automatically places the appropriate response code in the TCA 
at TCATDTR (TCATDBC if the language is ANS CCBCL) after completion 
cf the transient data service reguested. The application programmer 
must specify the entry labels (symbolic addresses) he requires to 
access the appropriate exception handling routine previously supplied 
by the user. 

If the application programmer does not use the EFHTD TYPE=CHECK 
macro instruction, he can specify the entry labels in either of two 
other ways: (1) by including the entry labels in operands of any ether 
LFHTD macro instruction, or (2) by coding instructions immediately 
following the DFHTD macro instruction that examine the response code 
provided by CICS at TCATD1R (1CATDRC if the language is ANS COEOL) 
and transfer control to the appropriate routine. 

The response codes are as fellows: 



CONDITION 


ASSEMBLER 


ANS CCBCL 


Ikll 


NOBESP 


X»00» 


12-0-1-8-9 


oooooooo 


QUEZEEO 


X'01* 


12-1-9 


COC00001 


IDEBBOB 


X»02» 


12-2-9 


C0000010 


ICEBBOR 


X'04 1 


12-U-9 


C0C00100 


NOTCFEN 


X»C8' 


12-8-9 


CC001CC0 


NOSPACE 


X' 10' 


12-11-1-8-9 


CG010000 



If the EFHTD TYPE=CHECK macro instruction is used by the application 
programmer, it should usually immediately fellow another DFHTD macro 
instruction. The applicable keywords are NOSESP, QUEZERO, IDERROB, 
ICERROR, NOTOEEN, and NOSPACE. 

Tf the application programmer does not check for a particular 
response to his service reguest, and if that exception condition occurs, 
program flew proceeds to the next sequential instruction. 

The operands that can be used to test the response to a request 
for transient data services are as follows. 

NORESP: Specifies the entry label of the user-written routine to which 
control is to be passed in the event no errors occur during a data 
set (file) operation. NORESP signifies "normal response" rather than 
"no response". 

CUEZEBO: Specifier the entry label of the user-written routine to 
which control is to be passed when the destination (gueue) accessed 
by a GET is found to be empty. This response applies to both 
intrapartition and extrapartiticn input queues. 

IDEEEOR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the symbolic destination 
identification referenced by a GET, PUT, or EEOV cannot be found. 
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ICEfFOR: Specifies the entry label of the user-written routine to 
which ccntrol is to be passed in the event an input/output error occurs 
en a data record and the data record in error is skipped. Transient 
Data returns an ICEBROB indication as long as the queue (destination) 
can te read, after which a QUEZERO response is returned; queue 
processing may then be restarted. 

NOTOPEN: Specifies the entry label of the user-written routine to 
■which ccntrcl is to be passed in the event a destination is closed. 

NOSPACE: Specifies the entry label of the user-written routine to 
which ccntrol is to be passed when it is determined that nc more space 
exists on a particular intrapartition queue or that the write request 
cannot be serviced. If the NOSPACE response is received, more data 
should not be written to this queue as it could be lost. 

The following are examples of the coding required to examine the 
response code provided by CTCS at TCATDTR (TCATDRC if the language 
is ANS CCBCI) and transfer control to the appropriate user-written 
exception handling routine. 

IQI Assembler language: 

EFHTD TYPE=GET, 

DESIID=CSML 
CLT TCATDTR,X«00' 
BE GOOD 
DFEF-C TYPE=AEEND 
GOOD DS OH 



ISI ANS CCEOL: 

DFHTD TYPE=GET, 

DESTID=CSML 
IF TCATEBC=' f THEN GC TO GOOD. 
DFHPC 1YPE=ABEND 
GOOD. 



where the value specified within single quotes is a multipunch code for 
the reguired hexadecimal value. For example, a hexadecimal 00 
has a multipunch code of 12-0-1-8-9. 

lor PIZI: 

DFHTD TYPE=GET, 

DESTID=CSML 
IF TCATDTR=»CCCC0000«B THEN GO TO GOOD; 
DFHPC TYPE=ABEND 
GOOD: 
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*EMPOHABY STOBAGE SEBVICJS 

Temporary Storage Management provides the facility, through Temporary 
Storage Control, that enables user-written application programs to 
store temporary data in main storage or on auxiliary storage (DASD) . 
Temporary data is stored, retrieved, and released using a unigue 
symbolic name (up to eight characters) assigned to the data by the 
originating task. 

Data stored in temporary storage can remain intact beyond the time 
that the originating task is terminated. That is, the originating 
task may be terminated and its transaction storage released; however, 
the data stored in temporary storage is still available under the 
symbolic name with which it was stored. The data remains intact until 
it is released by the user (the originating task or any other task) . 
Temporary data can be accessed any number of times until it is released. 

When temporary data is released, the space it occupies becomes 
reusable. If the data was stored in main storage, the area is released 
and returned to the available dynamic area. If the data was stored 
en auxiliary storage, the physical block becomes available and can 
be reused for other data. 

Temporary data can be retrieved by the originating task or any other 
task using the unigue user-supplied name. To avoid conflicts due to 
duplicate names, a naming convention must be devised by the user; for 
example, by appending the operator identification, terminal 
identification, or transaction identification as a prefix or suffix 
to the user-supplied symbolic name. 

When retrieving data. Temporary Storage Control always searches 
for the data in main storage before it searches in auxiliary storage. 

Except in the CICS/DOS-ENTRY system, main storage is used by 
Temporary storage Control to store small amounts of data (up to 256 
bytes) for short periods of time. For example, main storage might 
be used to pass data from task to task or for unigue storage that 
allows programs to meet the reguirement of CICS that they be guasi- 
reentrant (serially reusable between entry and exit points of the 
program) . If a reguest is made to store more than 256 bytes of data 
in main storage, the request automatically defaults to auxiliary 
storage. 

Auxiliary storage is used by Temporary Storage Control to contain 
data greater than 256 bytes in length and/or data that is to be kept 
for extended periods of time. Auxiliary temporary storage can also 
be used when reusable storage space is required. 

Possible uses of auxiliary storage by Temporary Storage Control 
include: 

1. Video paging. A task could retrieve a large master record from 
DASD, format it into several screen images, store the screen 
images on Temporary Storage auxiliary storage, and then ask 
the terminal operator which "page" (screen image) is desired. 
The user can provide coding (as a generalized routine or unique 
to a single application) to advance page by page, advance or 
back up a relative number of pages, etc. 

2- A "suspend data set". Assume a data collection task is in 

progress on a certain terminal. The task reads in one or more 
units of input and then allows the terminal operator to interrupt 
the process. If no interruption occurs (some kind of coded 
input) , the task repeats the data collection process. 
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If the operator interrupts the data collection stream with the 
coded input, the data collection task could output its 
"incomplete" data tc Temporary Storage and terminate the task. 
The terminal is now free to enter a completely different 
transaction (perhaps a high-priority inquiry) , When the terminal 
is available to continue the data collection operation, the 
operator initiates the task in a "resume" mode, causing the 
task to recall its suspended data from temporary storage and 
continue as though it had not been interrupted. 
3. An application that accepts input data which will be used for 
output on a preprinted form. 

The Temporary Storage Management macro instruction (DFHTS) is used 
to request any of the following services: 

1. Acguire data from a symbolic source in main or auxiliary storage. 

2. Send data to symbolic storage in main or auxiliary storage. 

3. "Release data from main or auxiliary storage. 

4. Check the response to a request for temporary storage services. 

The following operands can be included in the DFHTS macro 
instruction: 

DFHTS TYPE=PUT, * 

EATAID=name, * 

TSBADDR=symbclic address, * 

STORFAC=AUXILIARY,MAIN, * 

NCEESP=symbolic address* * 
INVREQ=symbolic address 

DFHTS TYPE=GET, * 

EATAID=name, * 

TSDADDR=symbclic address,YES, * 

RELEASE=YES,NO, * 

NCRESP=symbolic address, * 

IDEBEOR=symbclic address, * 
I0EE50B=synibclic address 

DFHTS 1YPE=RELEASE, * 

DATAID=name, * 

NCBESP=symbolic address, * 
IDEBBOR=symbclic address 

DFHTS TYPE=CHECK, * 

NCBESP=symbolic address, * 

IDEBEOR=symbclic address, * 

IOEEROR=symbclic address, * 
INVREQ=symbolic address 

STORE TEMPORARY DATA (POT) 

The application programmer can send temporary data to a symbolic 
source in main or auxiliary storage by issuing the 

DFHTS TYPE=PUT, * 

EATAIB-name, * 

TSDAEDR=symbclic address, * 

STORFAC=AUXILIARY,MAIN, * 

NORESP=symbolic address, * 
INVREQ=symtclic address 

macio instruction. The temporary data must have the standard variable-* 
length format, with the data length specified in the first four bytes 
(ILbb) followed by the data. IL is a two-byte binary length field 
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(the value of which includes the length of the data plus the four bytes 
for the length field) and bb is recommended to be a two-byte field 
cf binary zeros. 

The application programmer must specify the parameters he reguires 
to store temporary data. He can do this in either of two ways: (1) 
by including the parameters in operands of the DFHTS TYPE=PUT macro 
instruction, or (2) by coding instructions, prior to issuing the DFHTS 
TYPE=PUT macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in operands of 
the DFHTS TYPE=POT macro instruction, the applicable keywords are 
EATAID, TSDADDR, and STORJAC. 

A discussion of the operands that can be included in the DFHTS 
TYPE=PUT macro instruction follows. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Eeguest for Temporary Storage Services".) 

DATAID: Specifies the unigue alphameric name (one to eight characters) 
to be assigned to the temporary data to be stored. This operand can 
be omitted if the application programmer has previously placed the 
unigue alphameric name in the TCATSDI field of the TCA. 

TSDADDR: Specifies the symbolic address (half word aligned) of the 
temporary data to be stored. This operand can be omitted if the 
application programmer has previously placed the address in the TCATSDA 
field of the TCA. The data area is not released by the temporary data 
PUT. 

STORFAC: Specifies whether the temporary data is to be stored on 
auxiliary storage (AUXILIARY) or in main storage (MAIN) . The default 
is STORFAC=AUXILIARY. Any data greater than 256 bytes in length is 
automatically placed on auxiliary storage regardless of the user's 
reguest. 

The following are examples of the coding required to write a record 
to temporary storage. 

JPI Assembler l an guage: 

ISIOABAR EQU 7 

COPY DFHTSIOA 
DATA DS CL10 



MVC TSIOAVRI, LENGTH 

MVC EATA, MESSAGE 

DFHTS IYPE=PUT, * 

EATAID=UNIQNME, * 

1SDADDR=1SI0AVRL 
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For ANS COBOL; 



02 TSIOABAE PICTURE S9 (8) USAGE IS COMPUTATIONAL, 
01 DFHTSICA COPY BFHTSIOA. 
02 DATA PICTURE X(10). 



MOVE LENGTH TO TSIOAVRL. 
MOVE MESSAGE TO DATA. 
DFHTS TTPE=PUT r * 

DATAID=UNIQNME, * 

TSDADDR=TSIOAVRL 



291 2LZ.I' 



^INCLUDE DFHTSIOA; 

2 DATA CHAR(10) ; 



TSIOAVRL=LENGTH; 

BATA=MESSAGE; 

DFHTS TYPE=PUT, * 

DATAID=UNIQNME, * 

TSDADDR=TSIOAVRL 



RETRIEVE TEMPORARY EATA (GET) 

The application programmer can retrieve temporary data from a 
symbolic source in main or auxiliary storage by issuing the 

DFHTS TYPE=GET, * 

EATAID=name, * 

TSDADDR=symbclic address, YES r * 

RELEASE=YES,NO, * 

NORESP=symbolic address, * 

IDERBOR=symbclic address, * 
IOERROR=symbclic address 

macro instruction. Data retrieved from temporary storage is placed 

in either a user-provided storage area or an area (transaction storage) 

acquired for the user by Temporary Storage Control. 

The application programmer must specify the parameters he reguires 
to retrieve temporary data. He can do this in either of two ways: 
(1) by including the parameters in operands of the DFHTS TYPE=GET macro 
instruction, or (2) by coding instructions, £rior to issuing the DFHTS 
TYPE=GET macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in operands of 
the DFHTS TYPE=GET macro instruction, the applicable keywords are 
DATAID, TSDADDR, and RELEASE. 

A discussion of the operands that can be included in the DFHTS 
TYPE=GET macro instruction follows. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Request for Temporary Storage Services".) 
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DATAID: Specifies the name assigned to the temporary data at the time 
it was placed in temporary storage. This operand can be omitted if 
the application programmer has previously placed the name in the TCATSDI 
field of the TCA. 

TSEADDR: Specifies the symbolic name of the user-provided storage 
area into which the temporary data is to be read (cr moved) . 
TSDADDR=YES must be coded if the application programmer has previously 
placed this symbolic address in the TCA at TCATSDA. If this operand 
is omitted. Temporary Storage Control obtains a storage area, moves 
or reads temporary data into the area, and returns the address of the 
area to the user in the TCA at TCATSDA. 

EELEASE: Specifies whether the data is to be released following this 
acquisition. The default is RELEASE=NO. 

The following are examples of the coding required to read a record 
from temporary storage. In these examples, the data is moved to the 
area defined by the ujser in the TSDADDR operand. If the TSDADDR operand 
is omitted, the data is moved into a storage area obtained by Temporary 
Storage Control, and the address of the storage area is returned to 
the user at TCATSEA. 

1QI Assembler language: 

TSIOAEAR EQD 7 

COPY DFHTSIOA 



DFHTS TYPE=GET, * 

DATAIE=UNIQNME, * 

TSDADDR=TSIOAVRL 



for ANS COBOL: 

02 TSIOABAR PICTURE S9 (8) USAGE IS COMPUTATIONAL, 

01 DFHTSIOA COPY DFHTSIOA. 



DFHTS TYPE=GET, * 

DATAIE=UNIQNME, * 

TSDADDR=TSIOAVRL 
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IPX PiZI: 



^INCLUDE DFHTSIOA; 

2 DATA CHAR (10) ; 



DFHTS TYPE=GET, * 

BATAID=UNIQN!1E, * 

TSDADDR=TSTOAVRL 



RELEASE TEMPORARY EATA (RELEASE) 

The application programmer can release temporary data from main 
or auxiliary storage by issuing the 

DFHTS TYPE=RELEASE, * 

DATAID=name, * 

NCEESP=symbolic address, * 
IDERROR=symbclic address 

macro instruction. If the data was stored in main storage, the area 
is freed and returned to the available dynamic area. If the data was 
stored in auxiliary storage, the space is made available for other 
data. 

Temporary data should be released at the earliest possible time 
to avoid suspended tasks. 

A discussion of the EA r EAID=name operand of the DFHTS TYPE=RELEASE 
macro instruction fellows. (The keywords used to access user-written 
exception handling routines are discussed in the section "Test Response 
to a Request for Temporary Storage Services".) 

DATAID: Specifies the name assigned to the data to be released from 
temporary storage. This operand can be omitted if the application 
programmer has previously placed the name in the TCATSDI field of the 

TCA. 

The following are examples of the coding required to release a 
record from tempoiary storage. 

2°I Assembler language: 

MVC TCATSDI, =C»UNlC:NMF f 
DFHTS TYPE=RELEASE 



lor ANS CCBCL: 

MOVE ■UNIQUME' TO TCATSDI, 
DFHTS TYPE=RELEASE 



lor PLZI: 



TCATSDI='UNICNME' ; 
DFHTS TYPE=RELEASE 



129 



TEST RESPONSE TO A REQUEST FOR TEMPORARY STORAGE SERVICES (CHECK) 

One of the ways the application programmer can test the response 
to a request for temporary storage services is by issuing the 

DFHTS TYPE=CHECK, * 

NORESP=symtclic address, * 

IDEEROR=synibclic address, * 

I0EE50R=symbclic address, * 
INVREQ=symfcolic address 

macro instruction, which provides for the testing of response codes 
and the routing of control to the appropriate user-written exception 
handling routines. This macro instruction provides an exception 
handling facility that can be used in the manner of a subroutine. 

CICS automatically places the appropriate response code in the TCA 
at TCATSTR (TCATSRC if the language is ANS COBOL) after completion 
cf the temporary storage service requested. The application programmer 
must specify the entry labels (symbolic addresses) he requires to 
access the appropriate exception handling routine previously supplied 
by the user. 

The response codes are as fellows: 



CONDITION 


ASSEMBLER 


ANS COBOL 


Rhll 


NORESP 


X'OO' 


12-0-1-8-9 


cooooooo 


TDEBROR 


X'02» 


12-2-9 


0000C010 


IOERROR 


X'04» 


12-4-9 


00000100 


INVFEQ 


X'20» 


1 1-0-1-8-9 


00100000 



If the application programmer does not use the DFHTS TYPE=CHECK 
macro instruction, he can specify the entry labels (symbolic addresses) 
in either cf two other ways: (1) by including the entry labels in 
operands of any other DFHTS macro instruction, or (2) by coding 
instructions immediately following the DFHTS macro instruction that 
examine the response code provided by CICS at TCATSIR (TCATSRC if the 
language is ANS C030L) and transfer control to the appropriate routine. 

If the DFHTS TYPE=CHECK macro instruction is used by the application 
programmer, it should usually immediately fellow another DFHTS macro 
instruction. The applicable keywords are NORESP, IDERROR, IOERROR, 
and INVREQ. 

If the application programmer does not check for a particular 
response to his service request, and if that exception condition occurs, 
program flew proceeds to the next sequential instruction. 

The operands that can be used to test the response to a request 
for temporary storage services are as follows. 

NORESP: Specifies the entry label of the user-written routine to which 
control is to be passed in the event no errors occur during a Temporary 
Storage GET, PUT, or RELEASE. NORESP signifies "normal response" 
rather than "no response". 

IDERROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the symbolic destination 
identification referenced by a GET or RELEASE cannot be found in either 
main storage or auxiliary storage. 
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IOEFROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event an input/output error occurs 
during a GET operation en auxiliary storage. 

INVREQ: Specifies the entry label of the user-written routine to which 
control is to be passed in the event (1) a PUT is requested for data 
whose length is equal to zero or is greater than the block size of 
the auxiliary data set, or (2) the request is otherwise determined 
to be invalid. 

The following are examples of the coding required to examine the 
response code provided by CICS at TCATSTR (TCATSRC if the language 
is ANS COBOL) and transfer control to the appropriate user-written 
exception handling routine. 

IQL Assembler lang ua ge: 

DFHTS TYPE=GET, * 

DATAID=ONIQNME, * 

TSDADDR=YES 

CLI TCATSTR,X«00' 

BE GOOD 

DFHPC TYPE=AB1ND 
GOOD DS OH 



For ANS CCECL: 



DFHTS TYPE=GET, * 

DATATD=UNIQN?1E, * 

TSDADER=YES 

IF TCATSRC=« • THEN GO TO GOOD. 

CFHPC TYPE=ABEND 



GCOD. 



where the value specified within single guotes is a multipunch code 
for the required hexadecimal value. For example, a hexadecimal 00 
has a multipunch code of 12-0-1-8-9. 



for PL/I: 



DFHTS TYPE=GET, * 

DATAID=UNIQNME, * 

TSDADDR=YES 

IF TCATSTR=«CCC00COO'B THEN GO TO GOOD; 

DFEPC TYPE=ABEND 



GOOD: 
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TIME SEJVICES 

Time Management provides the capability, primarily through Interval 
Control and Task Control, to control various task functions based on 
the time ef day or on intervals of time. Time services include: 

1. Establish the partition/region exit time interval when CICS 
voluntarily relinquishes control tc the operating system. 

2. Provide system stall detection and corrective action (optional) 
based on the expiration of a user-provided time interval, in 
conjunction with other symptoms of a system stall condition. 

3. Provide runaway task detection and corrective action capabilities 
(optional) based on the expiration of a user-provided time 
interval with an executing application program apparently in 

a logical loop. 
U. Provide time of day in binary or packed decimal representation. 

5. Provide task synchronization based on time^dependent events. 

6. Provide automatic time-ordered task initiation with associated 
data retention and recovery support. 

The services enumerated in items 1-3 are CICS system services and 
require no action on the part of the application programmer. The 
services enumerated in items 4-6 are available to the application 
programmer through use of the Interval Control macro instruction 
(DFHIC) . 

The following operands can be included in the DFHIC macro 
instruction: 

DFHIC TYPE=GETIME, * 

FCBM=EINABY, PACKED, * 

TIMADB=symbclic address, YES, * 

NOHESP=symbolic address, * 
INVREQ=symbolic address 

DFHIC TYPE=WAIT, * 

INTRVAL=numeric value, YES, * 

TIME=numeric value, YES, * 

REQID=name, YES, * 

NCRESP=symbolic address, * 

INVREQ=symLclic address, * 
EXPIRD=symbolic address 

DFHIC TYPE=POST, * 

INTRVAL=numeric value, YES, * 

TIME=numeric value, YES, * 

EEQID=name,YES, * 

NORESP=symbolic address, * 

INVREQ=symbolic address, * 
EXPIRD=symbolic address 

DFHIC TYPE=INITIATE, * 

INTR7AL=numeric value, YES, * 

TIME=numeric value, YES, * 

REQID=name,YES, * 

TRANSID=name, * 

TRMIDNT=name,YES, * 

NCRESP=symbolic address, * 

INVREQ=symbolic address, * 

TRNIDER=symbclic address, * 
TRMIDER=symbclic address 

DFHIC TYPE=PUT, * 
INTRVAL-numeric value, YES, * 

TI ME"=numeric value, YES, __ *_ 
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EEQID=name,YES, * 

lBANSID=name, * 

TBHIENT=name,YES, * 

ICDADDB=symbclic address, YES, * 

NOBESP=symbclic address, * 

INVBEQ=symbolic address, * 

TBNIDEE=symbclic address, * 

TBMIDEE=symbclic address, * 
IOEBBOB=symbclic address 

DFHIC IYPE=GET, * 

TCDADDE=symbclic address, YES, * 

NCBESP=symbolic address, * 

INVBEQ=symtolic address, * 

ENDDATA=symbolic address, * 

NCTEND=symbclic address, * 
IOEBEOB=symbclic address 

DFHIC TYPE=BETBY, * 

NOBESP=symbolic address, * 

IflVBEQ=symbclic address, * 

NOTE ND=symbo lie address, * 
IOEEBOB=symfcclic address 

DEHIC TYPE=CANCEX, * 

EEQID=name,YES, * 

NGBESP=symbolic address, * 

INVBEQ=symbolic address, * 
NOTEND=symbclic address 

DEHIC TYPE=CHECK, * 

NOBESP=symbolic address, * 

ItfVBEQ.=symfco3,ic address, * 

EXPTED=symbclic address, * 

TBNIDEB=symbclic address, * 

TEMIDEB=syiabclic address, * 

IOEBBOB=symfcclic address, * 

NOTEND=symbclic address, * 
EUDDATA=symbclic address 

In the course cf normal operation, CICS maintains the current time 
of day within the Common System Area (CSA) ; in binary form at CSACTODB, 
and in packed decimal fcrm at CSATODP. These values are updated during 
task dispatching to reflect the time of day maintained by the operating 
system. The accuracy of these values depends upon the task mix and 
freguency of task switching occurences. 

Since the time of day maintained by the operating system can be 
changed either by the operating system (for example, OS resetting the 
clock to zero at midnight) or by the console operator, CICS must 
recognize the situation where a "negative" change in the time of day 
has occurred, and must adjust expiration times maintained by CICS 
accordingly. 

If the optional time adjustment feature of CICS Time Management 
is not included in CICS, any change to the operating system time of 
day involving midnight is represented by CICS as a value larger than 
the previous value (for example, 1:00 a.m. is represented as 2500 
hours). If the optional time adjustment feature is included in CICS, 
and if either the time-ordered task synchronization feature or automatic 
task initiation feature of CICS Time Management is also included, any 
change to the operating system time of day is automatically reflected 
in the expiration times maintained by CICS. 



133 



In the case of CICS/OS, when the operating system time of day is 
set to zero at midnight (and the time adjustment feature has been 
included in CICS) , CICS/OS adjusts the expiration times of day it 
nraintains and then resets its time of day to zero. In the case of 
both CICS/OS and CICS/DOS, when the operating system time of day is 
changed by the conscle operator to a value less than the previous 
value, CICS adjusts the expiration times it maintains to reflect the 
negative value and then resets its time of day to the time of day 
maintained by the operating system. The optional time adjustment 
feature thus makes it possible for CICS to be operated on a continuous 
round-the-clock basis. 

TIME-OF-DAY SERVICES (GETIME) 

In the course of normal operation, CICS maintains the current time 
of day in twc ferns within the Common System Area (CSA) ; in binary 
form at CSACTODB; and in packed decimal fcrm at C3ATODP. These values 
are updated periodically during task dispatching, their accuracy being 
dependent upon the task mix and frequency of task switching occurrences. 

Tasks can obtain a more current time of day by issuing the 

DFHIC TYPE=GETIME, * 

FCRM=BINARY, PACKED, * 

TIMADR=symbclic address, YES, * 

NCRESP=symfaclic address, * 
INVREQ=symbolic address 

macro instruction. This macro instruction causes one or both forms 
of the time of day to be updated in the CSA and, optionally, places 
the reguested fcrm of the time of day in a user-specified location. 
A discussion of the operands that can be included in the DFHIC 
TYPE=GETIHE macro instruction follows. (The keywords used to access 
user-written exception handling routines are discussed in the section 
"Test Response to a Request for Time Services".) 

FORM: This optional operand is used to indicate which representation 
of time of day is desired. The default is FORM=BINARY. 

FORM=PACKEE is used to indicate that the packed decimal 
representation cf the time of day is desired. The packed decimal 
representation is expressed as a four-byte positive signed value of 
the form FHMMSSt+ where the seconds are truncated to tenths of a second. 
The use of this operand causes both the packed and binary 
representations of the time of day to be updated and retained in the 
CSA. 

Jcrtei As a performance consideration, it should be taken into account 
that lengthy conversion routines are executed each time the 
FORM=PACKED operand is used. 

FCBM=BINABY is used when the binary representation of time of day 
is desired. The binary representation is expressed as a four-byte 
positive value in hundredths of a second. The use of this operand 
causes only the binary representation of time of day to be updated 
and retained in the CSA. 

1IHADR: This optional operand is used when the reguested time of day 
is tc be returne-d to a user-defined four-byte location. The application 
programmer can accomplish this in either of two ways: (1) by including 
the TIMADR=symbolic address operand in the DFHIC TYPE=GETIME macro 
i n s t r uct icn, or (2) by coding a single instxjflct_io.iL. px-tc r to issu ing 
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For ANS COBOL: 



02 TSIOABAB PICTURE S9 (8) USAGE IS COMPUTATIONAL. 
01 DFHTSIOA COPY DFHTSIOA. 
02 DATA PICTURE X(10). 



MOVE LENGTH TO TSIOAVRL. 
MOVE MESSAGE TO DATA. 
DFHTS TYPE=PUT, * 

DATAID=DNIQNME, * 

TSDADDR=TSIOAVRL 



lor PL/I: 



^INCLUDE DFHTSIOA; 

2 DATA CHAR (10) ; 



TSIOAVBL=LENGTH; 

DATA=MESSAGE; 

DFHTS TYPE=PUT, * 

DATAID=UNIQNME, * 

TSDADDR=TSIOAVRL 



EFTRIEVE TEMPORARY DATA (GET) 

The application programmer can retrieve temporary data from a 
symbolic source in main or auxiliary storage by issuing the 

DFHTS TYPE=GET, * 

EATAID=name, * 

TSDADDR=symbclic address, YES, * 

RELEASE=YES,NO, * 

NORESP=symbolic address, * 

IDEBEOR=symbclic address, * 
IOEREOR=symbclic address 

macro instruction. Data retrieved from temporary storage is placed 

in either a user-provided storage area or an area (transaction storage) 

acquired for the user by Temporary Storage Control. 

The application programmer must specify the parameters he requires 
to retrieve temporary data. He can do this in either of two ways: 
(1) by including the parameters in operands of the DFHTS TYPE=GET macro 
instruction, or (2) by coding instructions, £rior to issuing the DFHTS 
TYPE=GET macro instruction, that dynamically move these parameters 
to fields in the TCA. If the parameters are included in operands of 
the DFHTS TYPE=GET macro instruction, the applicable keywords are 
DATAID, TSDADDR, and RELEASE. 

A discussion of the operands that can be included in the DFHTS 
TYPE=GET macro instruction follows. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Request for Temporary Storage Services".) 
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BATATB: Specifies the name assigned to the temporary data at the time 
it was placed in temporary storage. This operand can be omitted if 
the application programmer has previously placed the name in the TCATSDI 
field of the TCA. 

1SIADDR: Specifies the symbolic name of the user-provided storage 
area into which the temporary data is to be read (or moved) . 
TSDADBR=YES must fce coded if the application programmer has previously 
placed this symbolic address in the TCA at TCATSDA. If this operand 
is omitted, Temporary Storage Control obtains a storage area, moves 
or reads temporary data into the area, and returns the address of the 
area to the user in the TCA at TCATSDA. 

RELEASE: Specifies whether the data is to be released following this 
acguisiticn. The default is RELEASE=NO. 

The following are examples of the coding required to read a record 
from temporary storage. In these examples, the data is moved to the 
area defined by the u.ser in the TSDADDR operand. If the TSDADDR operand 
is omitted, the data is moved into a storage area obtained by Temporary 
Storage Control, and the address of the storage area is returned to 
the user at TCATSIA. 

Jor Assembler language: 

1SI0AEAR EQD 7 

COPY DFHTSIOA 



DPHTS 1YPE=GET, * 

BATAIE=UNIQNME, * 

TSBABDR=TSIOAVRL 



lor A MS COBOL: 

02 TSIOABAR PICTURE S9(8) USAGE IS COMPUTATIONAL. 

01 DEHTSICA COPY BFHTSIOA. 



DFHTS TYPE=GET, * 

BATAIB=UNIQNME, * 

TSBADBR=TSIOAVRL 
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SSL SLZI' 



^INCLUDE DFHTSIOA; 

2 DATA CHAR(1C) ; 



DFHTS IYPE=GET, * 

DATAID=UNTQNME, * 

TSDADDR=TSIOAVRL 



RELEASE TEMPORARY DATA (RELEASE) 

The application programmer can release temporary data from main 
or auxiliary storage by issuing the 

DFHTS TYPE=RELEASE, * 

DATAID=name, * 

NORESP=symbolic address, * 
IDERROR=symbclic address 

macro instruction. If the data was stored in main storage, the area 
is freed and returned to the available dynamic area. If the data was 
stored in auxiliary storage, the space is made available for other 
data. 

Temporary data should be released at the earliest possible time 
to avoid suspended tasks. 

A discussion of the EA r £AID=name operand of the DFHTS TYPE=RELEASE 
macio instruction fellows. (The keywords used to access user ■'-written 
exception handling routines are discussed in the section "Test Response 
to a Request for Temporary Storage Services".) 

DATAID: Specifies the name assigned to the data to be released from 
temporary storage. This operand can be omitted if the application 
programmer has previously placed the name in the TCATSDI field of the 

TCA. 

The following are examples of the coding required to release a 
record from temporary storage. 

IQI £ss€rabler lang uag e: 

MVC TCATSDI, =C«UNIg:^MF , 
DFHTS TYPE=RELEASE 



1QL hM CCBCL: 

MOVE 'UNTQHME' TO TCATSDI, 
DFHTS TYPE=RELEASE 



For JL^I: 



TCATSDI= , UNIQNME« ; 
DFHTS TYPE=RELEASE 
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1EST RESPONSE TO A REQUEST FOR TEMPORARY STORAGE SERVICES (CHECK) 

One of the ways the application programmer can test the response 
to a request for temporary storage services is by issuing the 

DFHTS TYPE=CHECK, * 

NORESP=symbclic address, * 

IDEEEOR=symbclic address, * 

IOEESOR=symbclic address, * 
INVREQ=symfcolic address 

macro instruction, which provides for the testing of response codes 
and the routing of control to the appropriate user-written exception 
handling routines. This macro instruction provides an exception 
handling facility that can be used in the manner of a subroutine. 

CICS automatically places the appropriate response code in the TCA 
at TCATSTR (TCATSRC if the language is ANS COBOL) after completion 
cf the temporary storage service requested. The application programmer 
must specify the entry labels (symbolic addresses) he requires to 
access the appropriate exception handling routine previously supplied 
by the user. 

The response codes are as fellows: 



CONDITION 


ASSEMBLER 


ANS COBOL 


RL/1 


NOJESP 


X»00» 


. 12-0-1-8-9 


cooooooo 


TDSBROR 


X»02» 


12-2-9 


00OOCO1O 


IOERROR 


X'04' 


12-4-9 


00000100 


INVREQ 


X»20» 


1 1-0-1-8-9 


00100000 



If the application programmer does not use the DFHTS TYPE=CHECK 
macro instruction, he can specify the pntry labels (symbolic addresses) 
in either cf two other ways: (1) by including the entry labels in 
operands of any other DFHTS macro instruction, or (2) by coding 
instructions immediately following the DFHTS macro instruction that 
examine the response code provided by CICS at TCATS1R (TCATSRC if the 
language is ANS C030L) and transfer control to the appropriate routine. 

If the DFHTS TYPE=CHECK macro instruction is used by the application 
programmer, it should usually immediately fellow another DFHTS macro 
instruction. The applicable keywords are NORESP, IDEFROR, IOERROR, 
and INVREQ. 

If the application programmer does not check for a particular 
response to his service reguest, and if that exception condition occurs, 
program flew proceeds to the next sequential instruction. 

The operands that can be used to test the response to a request 
for temporary storage services are as follows. 

NORESP: Specifies the entry label of the user-written routine to which 
control is to be passed in the event no errors occur during a Temporary 
Storage GET, PUT, or RELEASE. NORESP signifies "normal response" 
rather than "no response", 

IDERROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the symbolic destination 
identification referenced by a GET or RELEASE cannot be found in either 
main storage or auxiliary storage. 
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IOERROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event an input/output error occurs 
during a GET operation en auxiliary storage. 

INVREQ: Specifies the entry label of the user-written routine to which 
control is to be passed in the event (1) a PUT is requested for data 
whose length is egual to zero or is greater than the block size of 
the auxiliary data set, or (2) the request is otherwise determined 
to be invalid. 

The following are examples of the coding required to examine the 
response code provided by CICS at TCATSTR (TCATSRC if the language 
is ANS COBOL) and transfer control to the appropriate user-written 
exception handling routine. 

lor Assembler language: 

DFHTS TYPE=GET, * 

DATAID=ONIQNME, * 

TSDADDR=YES 

CLI TCATSTR, X^O' 

BE GOOD 

DFHPC TYPE=ABIND 
GOOD DS OH 



Eor AKS CCBCL: 



DFHTS TYPE=GET, * 

DATATD=UNIQNME, * 

TSDADER=YES 

IF TCATSRC=« ' THEN GO TC GOOD. 

EFHPC TYPE=ABEND 



GOOD. 



where the value specified within single quotes is a multipunch code 
for the required hexadecimal value. For example, a hexadecimal CO 
has a multipunch code of 12-0-1-8-9. 

For PL/I: 

DFHTS TYPE=GET, * 

DATAID=UNIQNME, * 

TSDADDR=YES 

IF TCATSTR=«CCC00OOO«B THEN GO TO GOOD; 

DFHPC TYPE=ABEND 
GOOD: 
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1IM SERVICES 

Time Management provides the capability, primarily through Interval 
Control and Task Control, to control various task functions based on 
the time ef day ox on intervals of time. Time services include: 
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The services enumerated in items 1-3 are CICS system services and 

reguire no action on the part of the application programmer. The 
services enumerated in items 4-6 are available to the application 

programmer through use of the Interval Control macro instruction 
(DFHIC) . 

The following operands can be included in the DFHIC macro 
instruction: 



DFHIC 1YPE=GETIME, 

FCBM=EINAEY, PACKED, 
TIMADB=symbclic address, YES, 
NOBESP=symbolic address, 
INVBEQ=symbolic address 

DFHIC TYPE=WAIT, 

INTBVAL=numeric value, YES, 
TIME=numeric value, YES, 
I3EQID=narae,YES, 
NCEESP=symbolic address, 
INVHEQ=symLolic address, 
EXPIBD=symbolic address 

DFHIC TYPE=POST, 

INTEVAL=numeric value, YES, 
TIME=numeric value, YES, 
BEQID=name,YES, 
NOBESP=symbolic address, 
INVBEQ=symbolic address, 
f.XPIED=symbolic address 

DFHIC TYPE=INITIATE, 

INTH7AL=numeric value, YES, 
TIME=numeric value, YES, 
BEQID=name,YES, 
TBANSID=name, 
TRMIDNT=narae,YES, 
NCBESP=symbolic address, 
INVBEQ=symfcolic address, 
TBNIDEB=symbclic address, 
THHIDEB=symbclic address 

DFHIC IYPE=PUT, 

INTBVAL-numeric value, YES, 
TIME'=numeric value, YES, 
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REQID=name,YES, * 

TRANSID=name, * 

TRMICNT=name,YES, * 

ICDADDR=symbclic address, YES, * 

NORESP=symfcclic address, * 

INVREQ=symbclic address, * 

TRNIDEB=symbclic address, * 

TRMIDER=symbclic address, * 
IOIBBOR=symbclic address 

DFHIC IYPE=GET, * 

TCDADDR=syrabclic address, YES, * 

NCBESP=symbolic address, * 

INVHEQ=symtolic address, * 

ENDDATA=symbolic address, * 

NGTFND=symbclic address, * 
IOEBROR=symbclic address 

DFHIC TYPE=RETRY, * 

NORESP=symbolic address, * 

IflVREQ=symbolic address, * 

NOTFND=symbolic address, * 
IOEEROR=symbclic address 

DFHIC TYPE=CANCEI, * 

EEQID=name,YES, * 

NCEESP=symbolic address, * 

INVBEQ=symfcolic address, * 
NOTFND=symbclic address 

DFHIC TYPE=CHECK, * 

NOBESP=symbolic address, * 

IfiVREQ=symbo3,ic address, * 

EXPIRD=symbclic address, * 

TRNIDER=symbclic address, * 

TRMIDER=syrabclic address, * 

IOEEBOR=symbclic address, * 

NOTFND=symbolic address, * 
EHBDATA=symbclic address 

In the course cf normal operation, CICS maintains the current time 
of day within the Common System Area (CSA) ; in binary form at CSACTODB, 
and in packed decimal fcrm at CSATODP. These values are updated during 
task dispatching to reflect the time of day maintained by the operating 
system. The accuracy of these values depends upon the task mix and 
freguency of task switching occurences. 

Since the time of day maintained by the operating system can be 
changed either by the operating system (fcr example, OS resetting the 
clock to zero at midnight) or by the console operator, CICS must 
recognize the situation where a "negative" change in the time of day 
has occurred, and must adjust expiration times maintained by CICS 
accordingly. 

If the optional time adjustment feature of CICS Time Management 
is not included in CICS, any change to the operating system time of 
day involving midnight is represented by CICS as a value larger than 
the previous value (for example, 1:00 a.m. is represented as 2500 
hours) . If the optional time adjustment feature is included in CICS, 
and if either the time-crdered task synchronization feature or automatic 
task initiation feature of CICS Time Management is also included, any 
change to the operating system time of day is automatically reflected 
in the expiration times maintained by CICS. 
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In the case of CICS/OS, when the operating system time of day is 
set to zero at midnight (and the time adjustment feature has been 
included in CICS) , CICS/OS adjusts the expiration times of day it 
nraintains and then resets its time of day to zero. In the case of 
both CICS/OS and CICS/DOS, when the operating system time of day is 
changed by the console operator to a value less than the previous 
value, CICS adjusts the expiration times it maintains to reflect the 
negative value and then resets its time of day to the time of day 
maintained by the operating system. The optional time adjustment 
feature thus makes it possible for CICS to be operated on a continuous 
round-the-clock basis. 

TIME-OF-DAY SERVICES (GETIME) 

In the course of normal operation, CICS maintains the current time 
of day in twc ferns within the Common System Area (CSA) ; in binary 
form at CSACTODB; and in packed decimal form at C3ATODP. These values 
are updated periodically during task dispatching, their accuracy being 
dependent upon the task mix and frequency of task switching occurrences. 

Tasks can obtain a more current time of day by issuing the 

DFHIC TYPE=GETIME, * 

FCRM=BINARY, PACKED, * 

TIMADE=symbclic address, YES, * 

NCRESP=symbclic address, * 
INVREQ=symbolic address 

macro instruction. This macro instruction causes one or both forms 
of the time of day to be updated in the CSA and, optionally, places 
the requested fcrm of the time of day in a user-specified location. 
A discussion of the operands that can be included in the DFHIC 
TYPE=GETIHE macro instruction follows. (The keywords used to access 
user-written exception handling routines are discussed in the section 
"Test Response to a Request for Time Services".) 

FORM: This optional operand is used to indicate which representation 
cf time of day is desired. The default is FORM=BINARY. 

FORM=PACKEE is used to indicate that the packed decimal 
representation cf the time of day is desired. The packed decimal 
representation is expressed as a four-byte positive signed value of 
the form PHMMSSt+ where the seconds are truncated to tenths of a second. 
The use of this operand causes both the packed and binary 
representations of the time of day to be updated and retained in the 
CSA. 

Not.®! As a performance consideration, it should be taken into account 
that lengthy conversion routines are executed each time the 
FORM=PACKED operand is used. 

FCBM=BINARY is used when the binary representation of time of day 
is desired. The binary representation is expressed as a four-byte 
positive value in hundredths of a second. The use of this operand 
causes only the binary representation of time of day to be updated 
and retained in the CSA. 

1IHADR: This optional operand is used when the reguested time of day 

is tc be returne-d to a user-defined four-byte location. The application 

programmer can accomplish this in either of two ways: (1) by including 

the TIMADR=symbolic address operand in the DFHIC TYPE=GETIME macro j 

instruction, or (2) by coding a single instruction, prior to issuing 

134 



the DFHIC TY?E=GETTME macro instruction, that dynamically moves the 
address to the TCAICDA field of the TCA. If the latter is used, the 
TIMADB=YES operand must also te included in the DFHIC TYPE=GETIME macro 
instruction. If this operand is omitted, only the appropriate fields 
in the CSA are updates. 

The following is an example of the coding required to request the 
time of day: 



D7HIC TYPE=GETIME, 
FOBM=PACKED, 
TIMADR=CLOCK 



REQUEST CURRENT TIME-OF-DAY * 
PACKED DECIMAL FORM * 

SYMBOLIC ADDRESS FOR RESPONSE 



The following are examples of the coding required to dynamically 
request the time of day. 



IQI Assembler language: 

HVC TCAICDA, =A (C1CCK) 



MOVE AEDR FOR RESPONSE TO TCA 



DFHIC TYPE=GETIME, 
JOBM=PACKED, 
TIMAER=YES 



REQUEST CtJBEENT TIME-OF-DAY * 
PACKED DECIMAL FORM * 

RESPONSE ADDRESS GIVEN 



131 £NS COBOL: 

MOVE CLOCKADR TO TCAICEA, 



NOTE MOVE ADDR FOR RESP TO TCA. 



DFHIC TYPE=GETIME, 
FOEM=PACKED, 
TIMADB=YES 



REQUEST CURRENT TIME-OF-DAY * 
PACKED DECIMAL FORM * 

RESEONSE ADDRESS GIVEN 



For PL/I: 

TCAICDA=ADDR (CLOCK) ; 



/♦MOVE ADDR FOR RESP TO TCA*/ 



DFHIC TYPE=GETIME, 
FCBM=£ACKED, 
TIMADB=YES 



BEQUEST CURRENT TIME-OF-DAY * 
PACKED DECIMAL FORM * 

RESPONSE ADDRESS GIVEN 



TIME-ORDERED TASK SYNCHRONIZATION (WAIT, POST) 

The task synchronization feature of CICS Time Management provides 
the capability to either delay the processing of a task until a 
specified time occurs or to signal a processing task when a specified 
interval cf time has elapsed. It also supports the cancellation of 
a pending time-ordered synchronization event by another task. (See 
"Time-Ordered Request Cancellation" later in this section.) 

S^lay the Processing of a Task (WAIT) 

The application prograitmer can request that the processing of a 
task be suspended until a given time expires by issuing the 
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DFHIC TYPE=WAIT, * 

INTEVAL=numeric value, YES, * 

TIME=numeric value, YES, * 

EECID=name, YES, * 

NCEESP=syrabclic address, * 

INVEEQ=symfcolic address, * 

EXPIRD=symbolic address 

macro instruction. This macro instruction causes the task to 
temporarily suspend its own processing, and to resume control at a 
specified time of day or after a specified interval of time has elapsed. 
It supersedes and cancels any previously initiated DFHIC TYPE=POST 
request for the task. 

The application programmer must specify the parameters required 
in either cf twc ways: (1) by including the parameters in operands 
of the DFHIC TYPE=WAIT macro instruction, or (2) by coding instructions, 
pr io r to issuing the DFHIC TYPE=WAIT macro instruction, that dynamically 
move these parameters to fields in the TCA. If the parameters are 
included in operands of the DFHIC TYPE=WAIT macro instruction, the 
applicable keywords are INTRVAL, TIME, and EEQID. (The keywords used 
to access user-written exception handling routines are discussed in 
the section "Test Response to a Reguest for Time Services".) 

The numeric value specified in either the INTRVAL operand or TIME 
operand is used by CICS to calculate the time of day the requested 
time service is to be provided. If the calculated time of day is the 
same as the current clock time, or up to and including six hours 
preceding the current clock time, the specified time is considered 
to have elapsed (occurred) and the requested service is provided 
immediately. If the calculated time of day is in advance of the current 
clock time, the requested service is provided when the specified time 
occurs. If the calculated time of day precedes the current clock time 
by more than six hours, the requested service is provided the next 
day at the specified time. 

Note.; Users of CICS/OS miist be aware that the current clock time is 
reset to zero each day to represent midnight. CICS makes no 
attempt to calculate a time of day based on a clock time less 

than zero. 

t 

INTRVAL: This operand is used to specify the interval of time a task 
is to be suspended in response to a DFHIC TYPE=WAIT reguest. The 
interval of time is specified as a numeric value of the form HHMMSS, 
where HH represents hours f rem 00 to 99, MM represents minutes from 
CO to 59, and SS represents seconds from CO to 59. This numeric value 
is added to the current clock time by CICS when the DFHIC TYPE=WAIT 
macro instruction is executed to calculate the time of day (clock time) 
at which the posting is to occur. The minimum value that may be 
specified is one second. 

The numeric value can be specified in the DFHIC TYPE=WAIT macro 
instruction, or it can be dynamically moved to the TCAICRT field of 
the TCA prior to issuing the DFHIC TYPE=WAIT macro instruction. In 
the latter case, the INTEVAL=YES operand must be included in the macro 
instruction. 

The INTEVAL operand and TIME operand are mutually exclusive and 
rcay not be used in the same macro instruction. 

TIME: This operand is used to specify the time of day at which the 
processing of a task is to begin. The time of day is expressed as 
a numeric value of the form HHMMSS, where HH represents hours from 
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CO to 99, MM represents minutes from 00 to 59, and SS represents seconds 
from 00 to 59. 

The numeric value can Be specified in the DFHIC TYPE=WAIT macro 
instruction, cr it can be dynamically moved to the TCAICRT field of 
the TCA prior tc issuing the DFHIC TYPE=WAIT macro instruction. In 
the latter case, the TIME=YES operand must be included in the macro 
instruction. 

The TIME operand and TNTRVAL operand are mutually exclusive and 
may not be used in the same macro instruction. 

BEQID: Each time-ordered request has a unique Request Identification 
assigned to it. Its purpose is to provide a means of symbolically 
identifying the request and any data associated with it. Unless 
otherwise instructed, CICS generates a unique Request Identification. 

The optional BEQID operand allows the user to supply the unique 
Request Identification as part of the DFHIC TYPE=WAIT service request 
in either of two ways: (1) by specifying a maximum of eight characters 
in the REQID operand, or (2) by dynamically moving an eight-byte Request 
Identification to the TCAICQID field prior to issuing the DFHIC 
TYPE=WAIT macro instruction. In the latter case, the REQID=YES operand 
must be included in the macro instruction. 

The REQID operand should be used when a task issues the DFHIC 
TYPE=w"AIT macro instruction, if the application programmer wishes to 
provide another task with the capability of cancelling the unexpired 
WAIT request. (See the discussion of the DFHIC TYPE=CANCEL macro 
instruction. ) 

The following is an example of the coding required to temporarily 
suspend the processing of a task for a specified period of time: 



DFHIC TYPE=WAIT, 

IN1RVAI=500, 
EECir=GXLBZQHR 



DELAY TASK PROCESSING, 
WAIT 5 MINUTES SECONDS 
UNIQUE REQUEST ID 



The following are examples of the coding required to dynamically 
request the suspension of a task until a specified time of day. 



IQL Assembler lanquaqe: 

MVC TCAICRT, = PL4« 124500 1 
MVC TCAICQID, UNIQCODE 



MOVE 12:45 TO TCA 
UNIQUE REQUEST ID TO TCA 



DFHIC IYPE=WAIT, 
TIME=YES, 
REQID=YES 



DELAY TASK PROCESSING 
EXPIRATION TIME GIVEN 
UNIQUE ID GIVEN 



For ANS COBOL: 



MOVE 124500 TO TCAICRT. 
MOVE UNIQCCDE TO TCAICQID, 



NOTE MOVE 12:45 TO TCA 

NOTE UNIQUE REQUEST ID TO TCA, 



DFHIC TYPE=tfAIT, 
TIME=YES, 
REQID=YES 



DELAY TASK EROCESSING± 
EXPIRATION TIME GIVEN 
UNIQUE ID GIVEN 
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For PI/I: 



TCAICET=124500; 
TCAICQID=UNIQCODE; 



/*MOVE 12:45 TO TCA*/ 
/*UNIQUE BEQUEST ID TO TCA*/ 



DFHIC TYPE=WAIT, 
TIME=YES, 
EECID=YES 



DELAY TASK PPOCESSING 
EXPIRATION TIME GIVEN 
UNIQUE ID GIVEN 



Signal the Expiration of a Specified Time (POST) 

The application programmer can reguest that CICS indicate to a 
processing task when a given time has expired by issuing the 

DFHIC TYPE=POST, 

INTBVAL=numeric value, YES, 
TIME=numeric value # YES, 
FEQID=name,YES, 
NOBESP=symbolic address, 
INVBEQ=symbolic address, 
EXPIED=symbolic address 

macro instruction. In response to this macro instruction, CICS sets 
a series of bits in a Timer Event Control Area available to the user 
for testing. The address of the Timer Event Control Area is returned 
to the reguesting task in the TCAICTEC field after issuing the DFHIC 
TYPE=POST macro instruction. 

The Timer Event Control Area provided by CICS is a four-byte storage 
area initialized to binary zeros at the time the DFHIC TYPE=POST macro 
instruction is issued. Alien CICS determines that the specified time 
has expired, byte is set to a hexadecimal 40 and byte 2 is set to 
a hexadecimal 80 (the other bytes are set to zero) . This form of 
posting is compatible with the completion code postings performed by 
the operating systems. The Timer Event Control Area can be used as 
the Event Control Area referenced in a DFHKC TYPE=flAIT macro 
instruction. (See the discussion of task synchronization in the section 
"Task Services".) 

The Timer Event Control Area provided to the user is not released 
or altered (except as described above) until the first of any of the 
following events occur: 

1. The task issues a subseguent DFHIC TYPE=WAIT, DFHIC TYPE=POST, 
DFHIC TYFE=INITIATE or DFHIC TYPE=FUT macro reguest. 

2. The task issues a DFHIC TYPE=CANCEI macro reguest on behalf 
of its own previously issued DFHIC TYPE=POST reguest (this 
releases the storage area occupied by the Timer Event Control 
Area) . 

3. The task terminates, normally or abnormally. 

A task can only have one DFHIC TYPE=POST reguest active at any given 
time. Any DFHIC TYPE=WAIT, DFHIC TYPE=POST, DFHIC TYPE=INITIATE, or 
EFHIC TYPF=P0T reguest supersedes and cancels a previously issued DFHIC 
TYPE=POST reguest made by the task. 

ISi^l The expiration of any CICS time-ordered event is determined 
by CICS when it is performing its task dispatching function. 
Therefore, for "posting" to occur, the application programmer 
must ensure that the task relinquishes control of CICS before 
each testing of the Timer Event Control Area. This can be done 
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directly by issuing the DFHKC TYPE=WAIT macro instruction (see 

th€ discussion of task synchronization in the section "Task 

Services") or indirectly by requesting a CICS service which 

in turn initiates a task service on behalf of the task. 

The application programmer must specify the parameters required 
in either of two ways: (1) by including the parameters in operands 
of the DFHIC TYEE=POST macro instruction, or (2) by coding instructions, 
prior to issuing the DFHIC TYPE=POST macro instruction* that dynamically 
move these parameters to fields in the TCA. If the parameters are 
included in operands of the DFHIC TYPE=POST macro instruction, the 
applicable keywords are IHTRVAL, TIME, and REQID. (The keywords used 
to access irser-written exception handling routines are discussed in 
the section "Test Response to a Request for Time Services".) 

The numeric value specified in either the INTRVAI operand or TIME 
operand is used by CICS to calculate the time of day the requested 
time service is to be provided. If the calculated time of day is the 
same as the current clock time, or up to and including six hours 
preceding the current clock time, the specified time is considered 
to have elapsed (occurred) and the requested service is provided 
immediately. If the calculated time of day is in advance of the current 
clock time, the requested service is provided when the specified time 
occurs. If the calculated time of day precedes the current clock time 
by more than six hours, the requested service is provided the next 
day at the specified time. 

Note : Users of CICS/OS must be aware that the current clock time is 
reset to zero each day to represent midnight, \cics makes no 
attempt to calculate a time of day based on a clock time less 
than zero. 

INTRVAL: This operand is used to specify the interval of time that 
is to elapse in response to a DFHIC TYPE=POST request. The interval 
of time is specified as a numeric value of the form HHMMSS, where HH 
represents hours frcm 00 to 99, MM represents minutes from 00 to 59, 
and SS represents seconds from 00 to 59. This numeric value is added 
to the current clock time by CICS when the DFHIC TYPE=POST macro 
instruction is executed to calculate the time of day (clock time) at 
which the task is to be resumed. The minimum value that may be 
specified is one second. 

The numeric value can be specified in the DFHIC TYPE=POST macro 
instruction, or it can be dynamically moved to the TCAI CRT field of 
the TCA pxioj: to issuing the DFHIC TYPE=POST macro instruction. In 
the latter case, the INTRVAL=YES operand must be included in the macro 
instruction. 

The INTRVAL operand and TIME operand are mutually exclusive and 
may not be used in the same macro instruction. 

TIME: This operand is used to specify the time of day at which the 
posting action in response to a DFHIC TYPE=POST request is to occur. 
The time of xlay is expressed as a numeric value of the .form HHMMSS, 
where HH represents hours from 00 to 99, MM represents minutes from 
00 to 59* and SS represents seconds from 00 to 59. 

The numeric value can be specified in the DFHIC TYPE=POST macro 
instruction, or it can be dynamically moved to the TCAICRT field of 
the TCA prior to issuing the DFHIC TYPE=POST macro instruction. In 
the latter case, the TIME=YES operand must be included in the macro 
instruction. 
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The TIME operand and INTBVAL operand are mutually exclusive and 
may not be used in the same macro instruction. 

HEQID: Each time-ordered request has a unique Request Identification 
assigned to it. Its purpose is to provide a means of symbolically 
identifying the r€guest and any data associated with it. Unless 
otherwise instructed, CICS generates a unique Request Identification. 

The optional REQID operand allows the user to supply the unique 
Request Identification as part of the DFHIC TYPE=POST service request 
in either of two ways: (1) fcy specifying a maximum of eight characters 
in the REQID operand, or (2) by dynamically moving an eight^byte Request 
Identification to the TCAICQID field prior to issuing the DFHIC 
TYPE=POST macro instruction. In' the latter case, the REQID=YES operand 
must be included in the macro instruction. 

If the REQID operand is omitted from the DFHIC TYPE=POST macro 
instruction, the unique Request Identification generated by CICS is 
returned to the user in the TCAICQID field. 

The following is an example of the coding reguired to request that 
CICS signal the task when a specified interval of time has elapsed: 



DFHIC TYPE=POST, 
INTRVAL=30 



SIGNAL WHEN INTERVAL PASSES 
INTERVAL IS 30 SECONDS 



The following are examples of the coding required to dynamically 
request that CICS signal the task when the specified time of day occurs. 



IQI Assembler language: 

mvc tcaicrt,packtim: 



STORE CALCULATED EXPIR TIME 



DFHIC TYEE=POST, 

TIME^YES 
MVC UNIQCODE, TCAICQID 



SIGNAL WHEN TIME OCCURS 

EXPIRATION TIME GIVEN 

SAVE CICS UNIQUE REQUEST ID 



IQT ANS COBOL: 

MOVE PACKTIME TO TCAICRT, 



NOTE STORE CALC EXPIR TIME. 



DFHIC TYPE^POST, 

TIME=YES 
MOVE TCAICQID TO UNIQCODE. 



SIGNAL WHEN TIME OCCURS 

EXPIRATION TIME GIVEN 

SAVE CICS UNIQUE REQUEST ID 



TCAICRT=PACKTIME; 



/♦STORE CALCULATED EXPIR TIME*/ 



DFHIC TYPE=POST, 

TIME=YES 
UNIQCODE=TCAICQID; 



SIGNAL WHEN TIME OCCURS 

EXPIRATION TIME GIVEN 

SAVE CICS UNIQUE REQUEST ID 
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AUTOMATIC TIME-ORDERED TASK INITIATION (INITIATE, POT) 

This feature of Time Management allows a task to initiate another 
task at seme future time and, optionally, to pass data to that task. 
The automatic task initiation services available through DFHIC macro 
instructions include: 

1. Bequest that a task be initiated at some future time. 

2. Request that data be stored for a task which is to be initiated 
at seme future time. 

2§sk Initiation Without Data (INITIATE) 

The application programmer can request that another task be initiated 
at some future time by issuing the: 

DFHIC TYPE=INITIATE, * 

INTRVAL=numeric value, YES, * 

TIME=numeric value, YES, * 

REQID=name,YES, * 

TEANSID=name, * 

TRMIDNT=narae,YES, * 

NCRESP=symtolic address, * 

INVREQ=symbclic address, * 

TRNIDER=symbclic address, * 
TRMIDER=symbclic address 

macro instruction. Through the use of this macro instruction the 
application programmer provides the symbolic Transaction Identification 
of the task to be initiated at seme future time and other information 
pertaining to the task. CICS queues the request until the specified 
time occurs. Then, as soon as all necessary resources are available 
(for example, a terminal) , the task is initiated. Only one task is 
initiated if multiple DFHIC TYPE=INITIATE requests (all for the same 
transaction and terminal) expire at the same time or prior to terminal 
availability. The DFHIC TYPE=INITIATE macro instruction is used when 
no data is to be passed to the future task. It supersedes and cancels 
any previously initiated DFHIC TYPE=POST request for the task. 

The application programmer must specify the parameters required 
in either of two ways: (1) by including the parameters in operands 
of the EFHIC TYPE=INITIATE macro instruction, or (2) by coding 
instructions, .prior to issuing the DFHIC TYPE=INITIATE macro 
instruction, that dynamically move these parameters to fields in the 
TCA. If the parameters are included in operands of the DFHIC 
TYPE=INITIATE macro instruction, the applicable keywords are INTRVAL, 
TIME, REQID, TRANSID, and TRMIDNT. (The keywords used to access user- 
written exception handling routines are discussed in the section "Test 
Response to a Request for Time Services".) 

The numeric value specified in either the INTRVAL operand or TIME 
operand is used by CICS tc calculate the time of day the requested 
time service is tc be provided. If the calculated time of day is the 
same as the current clock time, or up to and including six hours 
preceding the current clock time, the specified time is considered 
to have elapsed (occurred) and the requested service is provided 
immediately. If the calculated time of day is in advance of the current 
clock time, the requested service is provided when the specified time 
occurs. If the calculated time of day precedes the current clock time 
ty more than six hours, the requested service is provided the next 
day at the specified time. 

Notex Users of CICS/OS must be aware that the current clock time is 
reset to zero each day to represent midnight. CICS makes no 
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attempt to calculate a time of day based on a clock time less 
than zero. 

INTRVAL: This operand is used to specify the interval of time after 
which the task is to be automatically initiated in response to a 
DFHIC=TYPE=INITIATE request. The interval of time is specified as 
a numeric value of the form HHMMSS, where HH represents hours from 
00 to 99, MM represents minutes from 00 to 59, and SS represents seconds 
from 00 to 59. This numeric value is added to the current clock time 
by CICS when the DFHIC TYEE=INITlATE macro instruction is executed 
to calculate the time of day (clock time) at which the task is to be 
automatically initiated. The minimum value that may be specified is 
cne second. 

The numeric value can be specified in the DFHIC TYPE=INITIATE macro 
instruction, or it can be dynamically moved to the TCAICRT field of 
the TCA jjrJLor to issuing the DFHIC TYPE=INITIATE macro instruction. 
In the latter case, the INTRVAL=YES operand must be included in the 
macro instruction. 

The INTRVAL operand and TIME operand are mutually exclusive and 
may not be used in the same macro instruction. 

TIME: This operand is used to specify the time of day at which the 
task is to be automatically initiated in response to a DFHIC 
TYPE=INITIATE request. The time of day is expressed as a numeric value 
of the form HHMMSS, where HH represents hours from CO to 99, MM 
represents minutes from 00 to 59, and SS represents seconds from 00 
to 59. 

The numeric value can be specified in the DFHIC TYPE=INITIATE macro 
instruction, or it can be dynamically moved to the TCAICRT field of 
the TCA prior to issuing the DFHIC TYPE=INITIATE macro instruction. 
In the latter case, the TIME=YES operand must be included in the macro 
instruction. 

The TIME operand and INTRVAL operand are mutually exclusive and 
may not be used in the same macro instruction. 

REQID: Each time-ordered reguest has a unique Request Identification 
assigned to it. Its purpose is to provide a means of symbolically 
identifying the request. Unless otherwise instructed, CICS generates 
a unigue Reguest Identification. 

The optional REQID operand allows the user to supply the unique 
Request Identification as part of the DFHIC TYPE=INITIATE reguest in 
either of two ways: (1) by specifying a maximum of eight characters 
in the REQID operand or (2) by dynamically moving an eight-byte Reguest 
Identification to the TCAICQID field p rio r to issuing the DFHIC 
TYPE=INITIATE macro instruction. In the latter case, the REQID=YES 
operand must be included in the macro instruction. 

If the REQID operand is omitted from the DFHIC TYPE=INITIATE macro 
instruction, 'the Unique Reguest identification provided by CICS is 
returned to the user in the TCAICQID field. 

TRANSID: This operand is used to supply the symbolic Transaction 
Identification of the future task. This operand can be emitted provided 
the application programmer has placed the symbolic Transaction 
Identification in the TCAICTI field prior to issuing the DFHIC 
TYPE=INITIATE macro instruction. CICS validates the symbolic 
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Transaction Identification through a scan of the Program Control Table 
at the time of the initial macro request, providing a response code 
at TCAICTR (TCAICEC if the language is ANS COBOL) without servicing 
the request if it fails tc locate a matching Transaction Identification. 

TRMIDNT: This operand is used when the future task must communicate 
with a terminal. The symbolic Terminal Identification can be included 
in the DFHIC TYPE=INITIATE macro instruction, or can be dynamically 
moved to the TCAICTID £rior to issuing the DFHIC TYPE=INITIATE macro 
instruction. In the latter case, the TRMIDNT=YES operand must be 
included in the macro instruction. CICS validates the symbolic Terminal 
Identification through a scan of the Terminal Control Table at the 
time of the initial macro request, providinq a response code at TCAICTR 
(TCAICRC if the lanquaqe is ANS COBOL) without servicing the request 
if it fails to locate a raatchinq Terminal Identification. The TRMIDNT 
operand is omitted from the DFHIC TYPE=INITIATE macro instruction if 
no association with a terninal is required. 

The fcllowinq is an example of the codinq required to request 
automatic initiation of a task not associated with a terminal without 
passing data to the task: 



DFHIC TYPE=INITIATE, 
INTRVAL= 10000, 
TRANSID=TRNL 



REQUEST TASK INITIATION * 

IN ONE HOUR * 

TRANSACTION IDENTIFICATION 



The following are examples of the coding required to dynamically 
request automatic initiation of a task associated vith a terminal 
without passinq data to the task. 



121 Assembler lanquaqe: 

MVC TCAICRT,=PLU« 10000 1 , 
MVC TCAICTI,=CL4«TRNV 
MVC TCAICTID, =Cm»STA5» 



MOVE ONE HOUR TO TCA 
TRANSACTION ID TO TCA 
TERMINAL ID TO TCA 



DFHIC TYPE=INITIATE, 
INTRVAL-YES, 
TRMIDNT=YES 

MVC UNIQCODE,TCAICQID 



REQUEST TASK INITIATION 
INTERVAL OF TIME GIVEN 
TERMINAL ID GIVEN 
SAVE CICS UNIQUE REQUEST ID 



For ANS CCBCL: 



MOVE 10000 TO TCAICRT. 
MOVE »TRN1» TO TCAICTI. 
MOVE ■STAS 1 TO TCAICTID. 



NOTE MOVE ONE HOUR TO TCA 
NOTE TRANSACTION ID TO TCA 
NOTE TERMINAL ID TO TCA 



DFHIC TYPE=INITIATI, 

INTRVAL=YES, 

TRMIDNT=YES 
MOVE TCAICQID TO UNIQCODE, 



REQUEST TASK INITIATION 
INTERVAL OF TIME GIVEN 
TERMINAL ID GIVEN 
SAVE CICS UNIQUE REQUEST ID 



121 llll- 



TCAICRT= 10000; 

TCAICTI=«TBN1»; 

TCAICTID=«STA5«; 



/♦MOVE ONE HOUR TO TCA*/ 
/♦TRANSACTION ID TO TCA*/ 
/♦TERMINAL ID TO TCA*/ 
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DFHIC TYPE=INITIATE, 
INTRVAL=YES, 
TRMIDNT=YES 

0NIQCODE=TCAICQID; 



BEQUEST TASK INITIATION 
INTERVAL OF TIME GIVEN 
TERMINAL ID GIVEN 
SAVE CICS UNIQUE REQUEST ID 



J§sk Initiation with Data (PUT) 

Supported by CICS Temporary Storage Management , this facility allows 
the application programmer to pass data to another task that is to 
be initiated at some future time by issuing the 

DFHIC TYPE=PUT, 

INTRVAL=numeric value, YES, 
TIME=numeric value, YES, 
BEQID=name,YES, 
TBANSlD=name, 
TRMIDNT=name,YES, 
ICDADDR=symtclic address, YES, 
NORESP=symbolic address, 
INVREQ=symfcolic address, 
TRNIDER=symbclic address, 
TRMIDER=symfcclic address, 
IOEBB0R=symbclic address 

macro instruction. This macro instruction is used to provide the 
symbolic Transaction Identification, the location of the data to be 
stored, and other information applicable to the task to be initiated 
at some future time. CICS stores the data and queues the request until 
the specified interval of time has elapsed or the specified time of 
day has occurred. As scon as all necessary resources are available 
(for example, a terminal) the task is initiated. 

The DFHIC TYPE=PUT macro instruction is used only when data is to 
be passed to a task to be initiated at some future time. It supersedes 
and cancels any previously initiated DFHIC TYPE=POST request of the 
task. 

If the task to be initiated at some future time is associated with 
a terminal, the initial DFHIC TYPE=:PUT request causes the task to be 
initiated at the specified time. Subsequent PUT's, with the same 
Terminal identification, Transaction Identification, and expiration 
time as the initial PUT, are used to store data for subsequent retrieval 
by the initiated task. (See the section "Retrieve Time-Ordered Data".) 

If the task to be initiated at some future time is not associated 
with a terminal, each DFHIC TYPE=PUT request results in a task being 
initiated at the specified time. That is, only one physical data 
record is passed to the initiated task. (See the section "Retrieve 
Time-Ordered Data".) 

The application programmer must specify the parameters required 
in either of two ways: (1) by including the parameters in operands 
of the DFHIC TYPE=PUT macro instruction, or (2) by coding instructions, 
Eli2£ to issuing the DFHIC TYPE=PUT macro instruction, that dynamically 
move these parameters to fields in the TCA. If the parameters are 
included in operands of the DFHIC TYPE=PUT macro instruction, the 
applicable keywords are INTRVAL, TIME, REQID, TRANSID, TRMIDNT, and 
ICEADDR. (The keywords used to access user-written exception handling 
routines are discussed in the section "Test Response to a Request for 
Time Services".) 
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The numeric value specified in either the INTBVAL operand or TIME 
operand is used by CICS to calculate the time of day the requested 
time service is to be provided. If the calculated time of day is the 
same as the current clock time, or up to and including six hours 
preceding the current clock time, the specified time is considered 
to have elapsed (occurred) and the requested service is provided 
immediately. If the calculated time of day is in advance of the current 
clock time, the requested service is provided when the specified time 
occurs. If the calculated time of day precedes the current clock time 
by more than six hours, the requested service is provided the next 
day at the specified time. 

Note: Users of CICS/OS must be aware that the current clock time is 
reset to zero each day to represent midnight. CICS makes no 
attempt to calculate a time of day based on a clock time less 
than zero. 

INTBVAL: This operand is used to specify the interval of time after 
which the task is to be automatically initiated and/or data made 
available to the task in response to a DFHIC TYPE=PUT request. The 
interval of time is specified as a numeric value of the form HHMMSS, 
where HH represents hours from 00 to 99, MM represents minutes from 
00 to 59, and SS represents seconds from 00 to 59. This numeric value 
is added to the current clock time by CICS when the DFHIC TYPE=PUT 
macro instruction is executed to calculate the time of day (clock time) 
at which the task is to be automatically initiated and/or data made 
available to the task. The minimum value that may be specified is 
one second. 

The numeric value can be specified in the DFHIC TYPE=P0T macro 
instruction, or it can be dynamically moved to the TCAICFT field of 
the TCA pjcioj: to issuing the DFHIC TYPE=PUT macro instruction. In 
the latter case, the INTRVAL^YES operand must be included in the macro 
instruction. 

The INTBVAL operand and TIME operand are mutually exclusive and 
may not be used in the same macro instruction. 

TIME: This operand is used to specify the time of day at which the 
task is to be automatically initiated and/or data made available to 
the task in response to a DFHIC TY-PE=P0T request. The time of day 
is expressed as a numeric value of the form KHMMSS, where HH represents 
hours from 00 to 99, MM represents minutes from 00 to 59, and SS 
represents seconds from 00 to 59. 

The numeric value can be specified in the DFHIC TYPE=PUT macro 
instruction, or it can be dynamically moved to the TCAICET field of 
the TCA jarior to issuing the DFHIC TYPE=P0T macro instruction. In 
the latter case, the TIME=YES operand must be included in the macro 
instruction. 

The TIME operand and INTBVAL operand are mutually exclusive and 
may not be used in the same macro instruction. 

REQID: Each time-ordered request has a unique Bequest Identification 
assigned to it. Its purpose is to provide a means of symbolically 
identifying the reguest and any data associated with it. Unless 
otherwise instructed, CICS generates a unigue Bequest Identification. 

The optional EEQID operand allows the user to supply the unique 
Bequest Identification as part of the DFHIC TYPE=PUT service request 
in either of two ways: (1) by specifying a maximum of eight characters 
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in the REQTD operand, or (2) by dynamically moving an eight-byte Request 
Identification to the TCAiCQID field prior to issuing the DFHIC TYPE=POT 
macro instruction. In the latter case, tie REQID=YES operand must 
be included in the macro instruction. 

If the REQID operand is omitted from the DFHIC TYPE=POT macro 
instruction, the unique Request Identification generated by CICS is 
returned to the user in the TCAICQID field. The unique Request 
Identification becomes the symbolic name assigned to the data stored 
by CICS when servicing the DFHIC TYPE=PUT request. 

TRANSID: This operand is used to supply the symbolic Transaction 
Identification of the task to. be initiated at some future time. This 
operand can be omitted provided the application programmer has placed 
the symbolic Transaction Identification in the TCAICTI field prior 
to issuing the DFHIC TYPE=POT macro instruction. CICS validates the 
symbolic Transaction Identification through a scan of the Program 
Control Table at the time of the initial macro request, providing a 
response code at TCAICTR (TCAICRC if the language is ANS COBOL) without 
servicing the request if it fails tc locate a matching Transaction 
Identification. 

TRMIDNT: This operand is used when the task to be initiated at some 
future time must communicate with a terminal. The symbolic Terminal 
Identification can be coded in the macro instruction, or can be 
dynamically moved to the TCAICTID field prior to issuing the DFHIC 
1YPE=PUT macro instruction. In the latter case, the TRMIDNT=YES operand 
must be included in the macro instruction. 

CICS validates the symbolic Terminal Identification through a scan 
of the Terminal Control Table at the time of the initial macro request, 
providing a response code at TCAICTR (TCAICRC if the language is ANS 
COBOL) without servicing the request if it fails tc locate a matching 
Terminal Identification. The TRMIDNT operand is omitted from the DFHIC 
TYPE=PUT macro instruction if no association with a terminal is 
required. 

ICDADDR: This operand is used to supply the location of the data to 
be stored for the task that is to be initiated at some future time. 
The data must have the standard variable-length format, with the data 
length specified in the first four bytes (LLbb) followed by the data. 
LL is a two-byte binary length field (the value of which includes the 
length of the data plus the four bytes for the length field) and bb 
is recommended to be a two-byte field of binary zeros. The symbolic 
address can be coded in the DFHIC TYPE=PDT macro instruction, or can 
be dynamically moved to the TCAICDA field prior to issuing the DFHIC 
1YPE=PDT macro instruction. In the latter case, the ICDADDR=YES operand 
must be included in the macro instruction. 

The following is an example of the coding required to request 
automatic task initiation and/or request that time-ordered data be 
made available to a task associated with a terminal: 



DFHIC TYPE=PUT, 

TIME=173000, 
TRANSID=TRN2, 
TRMIDN1=STA3, 
ICDADDR=DATAFLD 



REQUEST TASK INITIATION * 

TIME IS 5:3-0 PM * 

TRANSACTION IDENTIFICATION * 

TERMINAL IDENTIFICATION * 
DATA ADDRESS 



The following are examples of the coding required to dynamically 
reguest automatic task initiation and/or request that time-ordered 
data be made available to a task associated with a terminal. 
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I°£ Assembler l anguag e; 



MVC TCAICRT,PACKTIME 
MVC TCAICQTD,UNIQCCDE 
MVC TCAICTI,=CL4'TBN2» 
MVC I-CAICHD^Cm'STAB 1 
MVC TCAICDA,=A(DATAFLD) 



CALCULATED EXPIR TIME TO TCA 
UNIQUE REQUEST ID TO TCA 
TRANSACTION ID TO TCA 
TERMINAL ID TO TCA 
ADDRESS OE DATA TO TCA 



DFHIC TYPE=PUT, 
TIME=YES, 
TRMIDNT=YES, 
BEQID=YES, 
ICEAEDR=YES 



REQUEST TASK INITIATION 
EXPIRATION TIME GIVEN 
TERMINAL ID GIVEN 
UNIQUE REQUEST ID GIVEN 
DATA ADDRESS GIVEN 



for ANS COBOL: 



MOVE PACKTIME TO TCAICRT. 
HCVE UNIQCCDE TO TCAICQID. 
MOVE 'TRN2 1 TO TCAICTI. 
MOVE »STA3« TO TCAICTID. 
MOVE BATADER TO TCAICDA. 



NOTE CALC EXPIR TIME TO TCA 
NOTE UNIQUE REQEST ID TO TCA, 
NOTE TRANSACTION ID TO TCA. 
NOTE TERMINAL ID TO TCA. 
NOTE ADDRESS OF DATA TO TCA. 



DEHIC TYPE=PUT, 
TIME=YES, 
TRMlDNT=YES, 
BEQID=YES, 
ICEADDR=YES 



REQUEST TASK INITIATION 
EXPIRATION TIME GIVEN 
TERMINAL ID GIVEN 
UNIQUE REQUEST ID GIVEN 
DATA ADDRESS GIVEN 



Jor PL/I: 



TCAICRI=PACKTIME; 
TCAICQID=UNIQCODE; 
TCAICTI= , TBN2»; 
TCAICTID='STA3«; 
TCAICDA=ADER(EATAELD) ; 



/*CALC EXPIR TIME TO TCA*/ 
/♦UNIQUE REQUEST ID TO TCA*/ 
/♦TRANSACTION ID TO TCA*/ 
/♦TERMINAL ID TO TCA*/ 
/♦ADDRESS OE DATA TO TCA*/ 



EEHIC TYPE=PUT, 
TIME=YES, 
TRMIDNT=YES, 
BEQID=YES, 
ICEADDR=YES 



REQUEST TASK INITIATION 
EXPIRATION TIME GIVEN 
TERMINAL ID GIVEN 
UNIQUE REQUEST ID GIVEN 
DATA ADDRESS GIVEN 



BETRIEVE TIME-OBDERED DATA (GET) 

Tasks can retrieve expired time- ordered data by issuing the 

DEHIC TYPE=GET, 

ICDADDR=symbclic address, YES, 
NCRESP=symbolic address, 
INVREQ=symfcclic address, 
ENDDATA=symbclic address, 
NOTEND=symtolic address, 
IOEBBOB=symbclic address 

macro instruction. This service is supported by the CICS Temporary 
Storage Management facility. 
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Only data from an expired DFHIC TYPE=POT request can be accessed 
via the DFHIC TYPE=GET macro instruction. All data stored via the 
DFHIC TYPE=PUT macro instruction must be retrieved via the DFHIC 
TYPE=GET macro instruction. 

Each originating DFHIC TYPE=POT request symbolically identifies 
the Transaction Identification of the task to receive the data, and 
if applicable, symbolically identifies the terminal associated with 
the task's operation. When CICS services a DFHIC TYPE=PDT reguest, 
it dees so in two steps; it first gueues the reguest for automatic 
task initiation at a specified time and then stores the data. When 
the specified time occurs, the task is ready to be initiated, and the 
stored data is then available for retrieval. 

A task not associated with a terminal that is initiated as a result 
cf an expired DFHIC TYPE=PUT reguest can access only the single data 
record associated with the original reguest, and dees so by issuing 
the EFHIC TYPE=GET macro instruction. An end-of-data condition occurs 
in response to the DFHIC TYPE=GET reguest when all data records have 
been retrieved for this task. The storage occupied by the data 
associated with the task is released upon execution of the DFHIC 
TYPE=GET reguest, or upon termination of the task (normally or 
abnormally) . 

A task associated with a terminal that is initiated as the result 
of an expired DFHIC TYPE=POT reguest, or that is active on the terminal 
at the time of expiration cf a DFHIC TYPE=POT reguest, can access all 
data records associated with the other expired DFHIC TYPE=PDT macro 
reguests, each having the same Transaction Identification, and Terminal 
Identification as the operating task. Therefore, a task associated 
with a terminal can retrieve all the expired data destined for the 
terminal and task by issuing consecutive DFHIC TYPE=GET reguests. 
Each expired data record is presented to the task in expiration time 
seguence. The automatic task initiation reguest associated with each 
data record retrieved is canceled by the DFHIC TYPE=GET reguest for 
that data, and the storage occupied by the data is released at the 
same time. 

CICS provides an end-of-data response at TCAICTR (TCAICRC if the 
language is ANS COBOL) when all expired data has been exhausted. CICS 
releases the storage occupied by the single data record associated 
with an expired DFHIC TYPE=PUT reguest, if that request also resulted 
in initiating the task and the task terminated (normally or abnormally) 
without retrieving the data. Subseguent expired DFHIC TYPE=P0T 
reguests, specifying the same Terminal Identification and Transaction 
Identification, result in new tasks being initiated unless the data 
associated with the expired POT reguest has been retrieved in response 
to a DFHIC TYPE=GE1 reguest. 

The application programmer must specify the parameters required 
in either of two ways: (1) by including the parameter in operands of 
the DFHIC TYPE=PDT macro instruction, or (2) by coding the instruction, 
.prior to issuing the DFHIC TYPE=PDT macro instruction, that dynamically 
moves the parameter to the field in the TCA. If the parameter is 
included in the operand of the DFHIC TYPE=PDT macro instruction, the 
applicable keyword is ICDADDB. (The keywords used to access user- 
written exception handling routines are discussed the section "Test 
Response to a Reguest for Time Services".) 

ICEADDR: This optional operand is used to specify the location of 
the storage area provided by the user into which the data is to be 
placed. The symbolic address can be coded in the DFHIC TYPE=GET macro 
instruction, or it can be dynamically moved to the TCAICDA field prior 
to issuing the EFHIC TYPE=GET macro instruction. In the latter case, 
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the ICDADDR=YES operand must be included in the macro instruction. 
The storage area provided by the user must be large enough to contain 
the four-byte length field (LLbb) and data record. If this operand 
is omitted, a storage area is acquired by CICS that is large enough 
to contain the four-byte length field (LLbb) and data record. Its 
address is returned to -the user in the TCAICDA field. 

The following is an example of the coding required to request 
retrieval of a time-ordered data record: 



DFHIC TYPE=GET, 

ICDADDR=DATAFLB 



RETRIEVE TIME-ORDERED DATA 
DSEB-EBOVICID EATA AREA 



The following are examples of the coding required to dynamically 
request retrieval of a time-ordered data record. 



iQL Assembler language: 

MVC TCAICDA, = A(DATAFLD) 



DATA FIELD ADDR TO TCA 



DFHIC TYPE=GET, 

ICDADBR=YES 



RETRIEVE TIME-0EDER5D DATA 
DATA EIELD ADDRESS GIVEN 



121 21§ COBOL: 

MOVE EATADDE TO TCAICDA. 



NOTE DATA FIELD ADDR TO TCA. 



DFHIC TYPE=GET r 

ICDADDR=YES 



RETRIEVE TIME-ORDERED EATA 



for PL/I: 

TCATCDA=ADER (EATAFLD) ; 



/*BATA FIELD ADDR TO TCA*/ 



DFHIC TYPE=GET, 

ICDADDR=YES 



RETRIEVE TIME-ORDERED DATA 



TIME-CRDERED REQUEST CANCELLATION (CANCEL) 

The application programmer can request that a previously issued 
time-ordered service request (DFHIC TYPE=WAIT, DFHIC TYPE=POST, DFHIC 
TYPE=INITIATE, or DFHIC TYPE=POT) be canceled by issuing the 

DFHIC TYPE=CANCEL, 

BEQID=name,YES, 
NCBESP=symbolic address, 
INVREQ=symbolic address, 
NOTFND=symbolic address 

macro instruction. The effect of the cancellation is dependent upon 
the presence or absence of the REQID operand in the DFHIC TYPE=CANCEL 
request and on the type of service request being canceled. 
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The keywords used to access user-written exception handling routines 
are discussed in the section "Test Response to a Request for Time 
Services". 

REQID: This operand is required when identifying the unexpired time- 
crdered request issued by a task other than the cancelling task, and 
can be supplied by the application programmer in either of two ways: 
(1) by specifying the unique Request Identification in the REQID 
operand, or (2) by dynamically moving the unigue Request Identification 
to the TCAICQID field prior to issuing the DPHIC TYPE=CANCEL macro 
instruction. In the latter case, the REQID=YES operand must be included 
in the macro instruction. 

Cancel an Interval Control POST Request 

A DFHIC TYPE=POST reguest can be canceled by the originating task 
or by another task through use of the DFHIC TYPE=CANCEL macro 
instruction. 

When the originating task cancels a previously issued DFHIC TYPE=POST 
reguest, the REQID operand must be emitted from the cancellation 
request. The cancellation reguest can be made either before or after 
expiration cf the original request. In either case, the storage 
occupied by the Timer Event Control Area is released and all reference 
to the original request is removed from the system. 

when a task other than the originating task cancels a previously 
issued DFHIC TYEE=POST request, the REQID operand ds required. The 
effect of the cancellation is the same as an early expiration of the 
original DFHIC TYPE=POST request. That is, the originating task's 
Timer Event Control Area is posted as though the original expiration 
tine had teen reached. 

Cancel an. Interval Control WAIT Re<iue.st 

A DFHIC TYPE=WAIT request can only be canceled prior to its 
expiration, and only by a task other than the originating task (the 
originating task being suspended for the duration of the reguest) . 
The REQID operand is reguired. The effect of the cancellation is the 
same as an early expiration of the original DFHIC TYPE=WAIT request. 
That is, the originating task resumes control (based on its normal 
dispatching priority) as though the original expiration time had been 
reached. 

Cancel an Interval Co ntro l INITIATE or PUT Re que st 

Any cancellation of a previously issued DFHIC TYPE=INITIATE or DFHIC 
TYPE=PDT reguest requires that the REQID operand be included in the 
EFHIC TYPE=CANCEL macro instruction. The effect of the cancellation 
is to remove the original reguest from the system, treating the original 
request as though it had never been made. The cancellation request 
is effective only prior to expiration of the original reguest. 

INPDT/ODTPUT ERBOR RETRY CAPABILITY (RETRY) 

When the response to a previously issued DFHIC TYPE=GET macro 
instruction indicates an I/O error, the application programmer can 
issue the 
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DFHIC TYPE=RETRY, 

HOBESP=symbclic address, 
INVREQ=symbolic address, 
NOTFflD=symbolic address, 
IOERROR=symbclic address 



macro instruction, requesting that CICS retry the retrieval operation. 
CICS attempts to perform the retrieval operation on the data record 
(whose symbolic eight-character identification is contained at TCAICQID) 
using the data area specified at TCAICDA. These fields are preset 
by CICS at the time the I/O error response was returned to the user. 

The keywords used to access user-written exception handling routines 
are discussed in the section "Test Response to a Request for Time 
Services". 

1EST RESPONSE TO A REQUEST FOR TIME SERVICES (CHECK) 

One of the ways the application programmer can test the response 
to a request for time services is by issuing the 

DFHIC TYPE=CHECK, * 

NOBESP=symbolic address, * 

EXPIRD=symbolic address, * 

IOEBBOR=symbclic address, * 

TRNIDER=symtclic address, * 

TRMIDER^symbclic address, * 

NOTFND=symbolic address, * 

ENDDATA=symbclic address, * 
IUVREQ=symbolic address 

macro instruction. It provides for the testing of response codes and 
the routing of control to the appropriate user-written exception 
handling routines. This macro instruction provides an exception 
handling facility that can be used in the manner of a subroutine. 

CICS automatically places the appropriate response code in the TCA 
at TCAICTR (TCAICRC if the language is ANS COBOL) after completion 
of the time service requested. The application programmer must specify 
the entry labels (symbolic addresses) he requires to access the 
appropriate exception handling routines previously supplied by the 
user. 

If the application programmer does not use the DFHIC TYPE=CHECK 
macro instruction, he can specify the entry labels in either of two 
other ways: (1) by including the entry labels in operands of any other 
IFHIC macro instruction, or (2) by coding instructions immediately 
following the DFHIC macro instruction that examine the response code 
provided by CICS at TCAICTR (TCAICRC if the language is ANS COBOL) 
and transfer control to the appropriate routine. 

The response codes are as follows: 



CONDITION 


ASSEMBLER 


AJS COBOL 


2LII 


HORESP 


X»00» 


12-0-1-8-9 


COOOOOOO 


EflEDATA 


X«01« 


12-1-9 


C0000001 


IOERROR 


X»04» 


12-4-9 


00000100 


TRUIDER 


X»11« 


11-1-9 


00010001 


TRMIDER 


X* 12* 


11-2-9 


000100 10 


EXPIRD 


X«20« 


11-0-1-8-9 


00100000 


HOTFND 


X»81« 


12-11-0-1 


10000001 


IHVBEQ 


X»FF» 


12-11-0-7-8-9 


11111111 
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If the TYPE=CHECK macro instruction is used by the application 
programmer, it should usually immediately fellow another DFHIC macro 
instruction. The applicable keywords are NORESP, EXPIRD, IOERROR, 
TRNIDER, TRMIDER, NOTFND, BNDDATA, and INVREQ. 

If the application programmer does not check for a particular 
response to his service reguest, and if that exception condition occurs, 
program flow proceeds to the next seguential instruction. 

The operands that can be used to test the response to a reguest 
for time services are as follows. 

NORESP: Specifies the entry label of the user-written routine to which 
control is to be passed in the event no errors occur. NORESP signifies 
"normal response" rather than "no response". 

EXPIRD: specifies the entry label of the user-written routine to which 
control is to be passed in the event the time specified in a DFHIC 
TYPE=POST or DFHIC TYPE=WAIT reguest had already expired at the time 
the reguest was issued. 

IOEEROR: Specifies the entry label of the user-written routine to 
which control is to be passed in the event an input/output error occurs 
during a DFHIC TYPE=GET or DFHIC TYPE=PUT operation on auxiliary 
storage. The DFHIC TYPE=RETRY macro instruction can be used in 
connection with the GET type of error handling routine. 

TRNIDER: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the symbolic Transaction 
Identification specified in the DFHIC TYPE=INITIATE or DFHIC TYPE=PDT 
reguest is not found in the Program Control Table (PCT) . 

TRMIDER: Specifies the entry label of the user-written routine to 
which control is to be passed in the event the symbolic Terminal 
Identification specified in the DFHIC TYPE=INITIATE or DFHIC TYPE=POT 
reguest is net found in the Terminal Control Table (TCT) . 

NOTFND: Specifies the- entry label of the user-written routine to which 
control is to be passed in the event the Reguest Identification 
specified in the DFHIC TYPE=CANCEI macro instruction fails to match 
an unexpired time-ordered reguest. It is also applicable to DFHIC 
TYPE=GET or DFHIC TYPE=RETRY reguests and signifies that the time- 
ordered data stored for retrieval through the DFHIC TYPE=POT macro 
instruction cannot be located using the unigue Reguest (data) 
Identification contained in TCAICQID at the time of this response. 

For example, the "data not found" condition occurs on a retrieval 
operation if some prior task retrieved the data stored under that 
symbolic identification directly through Temporary Storage facilities 
and then released the data area. This condition also occurs if the 
Request Identification associated with the original DFHIC TYPE=PDT 
reguest fails to remain a unigue identification. 

ENDDATA: Specifies the entry label of the user-written routine to 
which control is to be passed in the event nc more data is stored for 
the task issuing a DFHIC TYPE=GET reguest. It can be considered a 
normal end-of-file response when retrieving seguential time^ordered 
data records. 
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TNVREQ: Specifies the entry label of the user-written routine to which 
control is to be passed in the event the operational CICS does not 
support the optional requested service. It may also indicate that 
an invalid type of request code was received for processing by the 
Interval Control program. 
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APPLICATION PROGRAMMING CONSIDERATIONS 



PROGRAMMABLE DEVICE CONSIDERATIONS 

When BTAM is used by CICS for programmable binary synchronous 
communication line management, CICS initializes the communication line 
with a BTAM read initial (TI) ; the terminal response must be a write 
initial (TI) or the equivalent. If a user-written application program 
then issues a read, CICS issues a read continue (TT) to that line; 
if the program then issues a write, CICS issues a read interrupt (RVI) 
to that line. 

The programmable terminal response to a read interrupt must be "end 
of transmission" (EOT) , except that the EOT response may be preceded 
by writes to exhaust the contents of output buffers so long as the 
input buffer size (specified previously by the user during preparation 
of the Terminal Control Table) is not exceeded by this data. CICS 
issues a read continue until it receives an EOT, or until the input 
message exceeds the size of the input buffer (which is an error 
condition) . 

After receiving an EOT, CICS issues a write initial (TI) or the 
equivalent (depending on the type of line) . The programmable terminal 
response must be a read initial (TI) or the equivalent. 

If another write is issued by the application program, CICS issues 
a write continue (TT) to that line. If the program issues a read after 
it has issued a write, CICS turns the line around; the program must 
have relinquished use of the line through a write reset (TR) . (CTCS 
does not recognize a read interrupt.) 

To ensure that binary synchronous terminals (for example, System/360, 
1130, 2780) remain coordinated, CICS processes the data collection 
or data transmission transaction on a line to completion before it 
polls the other terminals on that line. 

n ote : Since the CICS system service programs (Sign On/Sign Off, Master 
Terminal, etc.) do not insert binary synchronous control 
characters into the data stream, these programs cannot be used 
with the 2780 Data Transmission Terminal or the 2980 General 
Banking Terminal System. 

The type of response required on the part of CICS and the user- 
written programmable terminal program to DFHTC macro instructions 
issued in a user-written application program is as follows: 



APPLICATION PROGRAM 



DFHTC TYPE=READ 
DFHTC TYPE=WRITE (note 2) 
(note 3) 

DFHTC TYPE=WRITE 

DFHTC TYPE=READ (note H) 

DFHTC TYPE=RESET 



CICS (note 1) 

READ INITIAL (TI) 
READ CONTINUE (TT) 
READ INTERRUPT (RVI) 
READ CONTINUE (TT) 
WRITE INITIAL (TT) 
WRITE CONTINUE (TT) 
WRITE RESET (TR) 
READ INITIAL (TI) 
WRITE RESET (TR) 



TERMINAL PROGRAM 

WRITE INITIAL 
WRITE CONTINUE 
WRITE RESET 

READ INITIAL 
READ CONTINUE 
READ CONTINUE 
WRITE INITIAL 



Note 1: CICS issues the equivalent of the macro instruction shown, 
depending upon whether the communication line is switched 
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or non-switched. The user-written programmable terminal 
program must issue the equivalent of the BTAM operation 
shown. 

Note 2: An RVI sequence is indicated by the DECFLAGS field of the 
Data Extent Control Block (DECB) being set to X'02' and a 
completion code of X ' 7F ' being returned to the Event Control 
Block (ECB) . 

Note_3: The read continue is issued only if the "end of transmission" 
(EOT) character is not received on the read interrupt. 

Note_4: Write reset is issued only for point-to-point terminals. 

3735 CONSIDERATIONS 

The 3735 Programmable Buffered Terminal is supported by CICS/OS and 
CICS/DOS-STANDARD as explained below. 

3735 Transactions - Autoanswer 

The 3735 transaction is attached by CICS upon receipt of input from 
a 3735. Data is passed to the application program in 476-byte blocks; 
each block (one buffer) may contain multiple logical records. The 
final block may be shorter than 476 bytes; however, zero-length final 
blocks are not passed to the application program. If the block contains 
multiple logical records, the user's application must perform any 
necessary deblocking functions and the gathering of partial logical 
records from consecutive reads.. 

It is recommended that the user spool input data from a 3735 to an 
intermediate data set to ensure that all data has been captured before 
deblocking and processing that data. 

The application must follow 3735 conventions and read to end-of-file 
before attempting to write FDP's (Form Description Programs) or data 
to the 3735. For this reason, the EOF=symbolic address operand must 
be used with each DFHTC TYPE=READ request. When the EOF branch is 
taken, the user may begin to write FDP's or data to the 3735, or, 
optionally, request CICS to disconnect the line. 

It is possible that the 3735 will transmit the end-of-file condition 
immediately upon connection of the line. For this reason the user must 
code the initialization request (DFHTC EOF=symbolic address) before 
issuing any other Terminal Control requests in his proqram. 

The user is responsible for formatting all special message headers 
for output to the 3735 (for example, SELECTRIC, POWERDOWN) . If FDP's 
are to be transmitted to a 3735 with ASCII transmission code, the 
NOTRANSLATE operand must be included in the DFHTC TYPE=WRITE reguest 
for each block of FDP records. 

The user must issue a DFHTC TYPE=DISCONNECT macro instruction when 
he has exhausted the output to be transmitted to the 3735. If the 
application program ends during Batch Write mode prior to issuing the 
DISCONNECT request, CICS forces a 3735 "receive abort" condition and 
all data just transmitted is ignored by the 3735. 
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3735 Transactions - Autocall 

In automatic and time-initiated transactions, all of the 
considerations contained in the section "3735 Transactions - Autoanswer" 
apply when CICS dials a 3735 with the exception that the DFHTC 
EOF=synibolic address macro instruction is not used. 
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CICS connects the line and allows the user to indicate the direction 
of data transfer by means of his first Terminal Control request. The 
user is cautioned, however, that if his first request is a WRITE and 
the 3735 has data to send, the 3735 causes the line to be disconnected. 

SYSTEM/7 CONSIDERATIONS 

The implementation of System/7 support treats the System/7 as any 
other proqrammable terminal. Transactions are normally initiated from 
the System/7 by issuinq a four-character transaction code as in the 
followinq example: 



SXMIT 

PBER 

PLEX 



TRNID 
ERROR 



TRANSMIT TRANSACTION CODE 
BRANCH IF CONDITION ERROR CODE 
WAIT FOR COMPLETION 



TRNID 


#IOLT 


3, CHECK, /0 000, TRAN, 2 


* 


#IOLT 




* 




3, 


* 






* 




CHECK, 


* 




/oooo, 


* 




TRAN, 


* 




2 


TRAN 


PEQU 


* 




PDC 


/A6D2 




PDC 


/CAOE 



GENERATE I/O LIST 

RETURN CONTROL ON INTERRUPT 

LEVEL 3 

RETURN CONTROL AT LOCATION CHECK 

TRANSMIT MESSAGE IN BCD MODE 

MESSAGE LOCATED AT TRAN 

MESSAGE TWO WORDS LONG 

TRANSACTION ID 

= «TR' 

= 'N7» 



CHECK PEQU 



TEXT FOR SUCCESSFUL COMPLETION 



In this example, the transaction identification is transmitted in 
BCD mode. Pseudo-binary mode may only be used while communicatinq with 
an active CICS transaction; it can never be used to initiate the 
transaction. Note that the messaqe lenqth is qiven as the number of 
words to be transmitted and not as the number of characters. 

When a transaction is initiated on a System/7, CICS services only 
that System/7 for the duration of the transaction; all other System/7* s 
on that line are locked out for the duration of the transaction to 
provide most efficient use of the line. Therefore, it is hiqhly 
recommended that CICS application proqrams be desiqned for the 
multipoint System/7 so that their execution is of short duration. 

It is an MSP/7 standard that the first word (two characters) of 
every messaqe received by the System/7 be an identification word. All 
identification words beqinninq with "3)" (X'20 1 ) are reserved for future 
use by CICS. 

When the PSEUDOBIN parameter is specified as part of an input 
request (for example, DFHTC TYPE= (READ, PSEUDOBIN) ) , the TIOA provided 
by the application proqram must be at least twice the lenqth of the 
data to be read. For example, if 20 System/7 words (40 bytes) are to 
be read, the data area of the TIOA must be at least 80 bytes in lenqth. 
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When the PSEUDOBTN parameter is specified as part of an output 
request, Terminal Control always obtains a new TIOA and frees the old 
TTOA unless SAVE was specified. Therefore, on a DFHTC 
TYPE= (WRITE, READ, PDEUDOBIN) request, the application program must 
reload the TIOA address (from TCTTEDA) to access the input data from 
the System/7. 

In the case of a System/7 on a dial-up (switched) line, the 
application program must initially transmit a four-character terminal 
identification. (This terminal identification is generated during 
preparation of the TCT through use of the DFHTCT TYPE=TERMINAL, 
TRMIDNT=parameter specification.) CTCS then responds with either a 
"ready" message, indicating that the terminal identification is valid 
and that the System/7 may proceed as if it were on a leased line, or 
an INVALID TERMINAL IDENTIFICATION message, indicating that the terminal 
identification sent by the System/7 did not match the TRMIDNT=parameter 
specification. 

Whenever CICS initiates the connection to a dial-up System/7, CICS 
writes a null message consisting of three idle characters prior to 
starting the transaction. As a result of this message transmission, 
a data check message may be recorded on the CICS (host) system console. 
This occurs if there is no program resident in the System/7 capable 
of supporting the Asynchronous Communication Control Adapter (ACCA) 
as is normally the case when the task to be initiated by CICS is to 
IPL the System/7. Although the BTAM error routines cause a data check 
message to be printed at the CICS console, CICS ignores this error 
and continues normal processing. 

If a program capable of supporting the ACCA is resident in the 
System/7 at the time of this message transmission, the data check will 
not occur. 

When a disconnect is issued to a dial-up System/7, the 'busy 1 bit 
is sometimes left on in the ACCA's interrupt status word. If the line 
connection is reestablished by dialing from the System/7 end, the 
'busy* condition of the ACCA prevents message transmission from the 
System/7. To overcome this problem, the System/7 program must reset 
the ACCA after every disconnect before message transmission is 
attempted. This may be accomplished by issuing a PIO instruction to 
reset the ACCA. The following instruction accomplishes this: 

PWRI 0,8,3,0 RESET ACCA 

This procedure is not necessary when the line is reconnected by CICS 
(that is, by an automatically initiated transaction) . 

NQN-PROGRAMMABLE DEVICE CONSIDERATIONS 

This section includes various considerations for the application 
programmer as he designs applications for non-programmable terminals. 

2260/2265 PROGRAMMING CONSIDERATIONS 

The following is an example of the coding required to write data 
to a 2260/2265 terminal and specify the screen line address where the 
write is to begin: 

DFHTC TYPE=WRITE, WRITE DATA TO A TERMINAL SCREEN * 

LINEADR=10 STARTING AT THIS SCREEN LINE 



157 



^he following are examples of the coding required to write data 
to a 2260/2265 terminal and dynamically determine the screen line 
address where the write is to begin. 



121 Assembler lan gua ge: 

MVI TIOALAC,X*F0" 



WRITE STARTING AT SCREEN LINE 1 



DFHTC TYPE=WRITE, 
LINEADR=YES 



WRITE DATA TO A TERMINAL SCREEN 
STARTING LINE ALREADY SPECIFIED 



I9.E ANS COBOL: 

MOVE 240 TO TIOALAC. 



NOTE PLACE STARTING LINE IN TIOA. 



DPHTC TYPE=WRITE, 
LINEADR=YES 



WRITE DATA TO A TERMINAL SCREEN 
STAPLING LINE ALREADY SPECIFIED 



for PL/I: 

TIOALAC=240; 



/♦START *?RITE AT SCREEN LINE 1*/ 



DFHTC TYPE=WRITE, 
LINEADR=YES 



WRITE DATA TO A TERMINAL SCREEN 
STARTING LINE ALREADY SPECIFIED 



2770/2780 PROGRAMMING CONSIDERATIONS 

The 2770 Data Communication System and 2780 Data Transmission 
Terminal recognize a read interrupt and respond by transmitting the 
contents of the I/O buffer. After the contents of the buffer have 
been transmitted, the 2770 or 2780 responds to the next read continue 
with an EOT. If the I/O buffer is empty, the 2770 or 2780 transmits 
an EOT. CICS issues a read interrupt and read continue to relinquish 
use of the line and to enable the user to write to the 2770 or 2780. 

Input from a 2*770 or 2780 consists of one or more logical records. 
CICS provides the user with one logical record per read reguest. Note 
that the size of a logical record cannot exceed the contents of one 
buffer. 

Output to a 2780 requires that the application programmer insert 
the appropriate "escape seguence" for component selection associated 
with the output message. 

A read issued to a 2770 causes a logical record to be presented 
to the application program. If the input spans multiple buffers, 
multiple reads must be issued by the application program. 
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2980 PROGRAMMING CONSIDERATIONS 

Passbook Control for the 2980 

When writing application programs to service the 2980 General Banking 
Terminal System, the application programmer must be aware of the 
passbook control considerations described in this section. 

Two one-byte fields of the Terminal Control Table terminal entry 
(TCTTE) may be interrogated by the application program while servicing 
passbook requests from the 2980. These fields are: 

1. TCTTETAB, which contains the binary representation of the number 
of tabs necessary to position the print element at the passbook 
area. 

2. TCTTEPCF, which contains the indicators (flags) necessary for 
passbook control operations. The indicators TCTTEPCR and 
TCTTEPCW indicate whether or not the passbook is present on 

a read or write operation, respectively. The same indicators 
are used to indicate the presence of the auditor key on the 
2980 Model 2. 

By testing indicators TCTTEPCR and TCTTEPCW, positive control can 
be maintained by the application program with regard to the absence 
or presence of a passbook during an update operation. However, care 
must be taken to never alter these indicators or unpredictable results 
may occur. 

If the passbook is present on a read (entry) operation, the TCTTEPCR 
indicator is turned on (set to a binary one) . In this case, the 
application program generally issues a write operation back to the 
passbook area to update the passbook. After the write operation, the 
application program must check the TCTTEPCW indicator to ensure that 
the passbook was present at the time the write occurred. If the 
TCTTEPCW indicator is off (set to a binary zero) , the passbook was 
not present and the write operation did not occur. However, the data 
sent to the terminal (and not printed because of the "no passbook" 
condition) is returned to the application program in its original form 
for subsequent retransmission. 

When the "no passbook" condition occurs on a write, CICS allows 
an immediate write to the terminal. The application program should 
generally write an error message to the journal area of the terminal 
informing the 2980 operator of this error condition. Then CICS 
automatically causes the transaction to wait for 23.5 seconds before 
continuing execution to allow the operator to insert the required 
passbook. 

After regaining control from CICS following the writing of the error 
message, the application program can attempt another write to the 
passbook area after ensuring that the print element is positioned 
correctly in the passbook area. This is generally accomplished by 
issuing two carrier returns followed by the number of tabs required 
to move the print element to the correct position. The specification 
of the correct number of tabs may be acquired from the field at 

TCTTETAB. 

If the TCTTEPCW indicator is still off following the second attempt 
to write to the passbook area, the application program can send another 
error message or take some alternate action (for example, place the 
terminal "out of service") . 
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In summary, all writes to the passbook area are conditional. That 
is r all writes reguire the presence of the passbook before they can 
be successfully executed. Therefore, a read operation cannot be 
combined with a passbook write. For example, a 

DFRTC TYPE= (WRITE, BEAD, WATT) 

macro instruction is an invalid request for 2980 terminal services 
involving the passbook area. 

Note : The application programmer should not insert shift characters 
in output data since this is done automatically by CICS. CICS 
removes shift characters from input data. 

Segm ente d Writes Control for the 2980 

Segmented writes are supported for both the journal area and the 
passbook area. Journal area segmented writes are limited in length 
by the hexadecimal halfword value that the user stores in TIOATDL. 
Passbook segmented writes are limited to a one-line logical write to 
ensure positive control of the passbook as it spaces (indexes) past 
the bottom of the passbook. 

For example, consider a 2982 buffer length of 48 and a 2980 Hodel 
4 loqical write (print) area of 100 characters per line. The user 
can write a logical record (DFHTC TYPE=PASSBK) of 100 characters to 
this area and it will be segmented by CICS because of buffer size. 
The user is required to insert the passbook indexing character (X f 25') 
as the last character written in any one logical write to the passbook 
area. This is done to control passbook indexing and thereby achieve 
positive control of passbook presence. 

If the message contains embeddded passbook index characters and 
the logical length of the message is such as to cause segmenting, the 
write terminates if the passbook spaces past the bottom of the passbook; 
the remaining segments are not printed. 

'Data Han dling for the 2980 

SHIFT CHARACTERS: Shift characters are handled by the Terminal Control 
program and are of no concern to the application programmer. They 
are stripped from input messages and are added to output messages as 
required. Data can be written in any mix of uppercase, lowercase, 
or special characters. (See the 2980 Translate Tables in Appendix 
E.) 

JOURNAL INDEXING: Journal indexing is the responsibility of the 
application programmer. Carriage returns (X'15 1 ) may be inserted 
anywhere in the logical message. 

PASSBOOK INDEXING: passbook indexing requires special consideration 
by the application programmer to control bottom line printing on the 
passbook. (See the section "Passbook Control for the 2980" and the 
section "Segmented Writes Control for the 2980".) 

TAB CHARACTERS: The tab character (X'05») is also controlled by the 
application programmer. The number of tabs reguired to position the 
type element to the first position of the passbook is located in the 
TCTTE at TCTTETAB. This value is specified by the user when generating 
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the Terminal Control Table and may be unique to each terminal. Other 
tab characters are inserted as needed to control output format. 

MISCELLANEOUS CHARACTERS: Turn page, message lite, openchute, and 
special banking characters can be used by the application programmer 
as needed. (See the 2980 Translate Tables in Appendix E.) 

AUDITOR KEY MODEL 2: Presence of the Auditor key is controlled through 
use of the DFHTC TYPE=PASSBK macro instruction and may be used in a 
manner similar to that for passbook control. (See the section "Passbook 
Control for the 2980) . 

2980 MODEL NUMBER: The TCTTETM field of the Terminal Control Table 
terminal entry (TCTTE) contains the 2980 model number expressed as 
a hexadecimal value (X'OI 1 , X , 02 l , X^U 1 )* CICS uses the model number 
to select the correct Translate Table for each of the 2980 models; 
therefore, the user cannot alter this field. 

COMMON BUFFER: Common buffer writes (DFHTC TYPE=CBUFF) are translated 
to the receiving TCTTE model character set. If more than one 2980 
model type is connected to the 2972 Control Unit, the lengths are 
automatically truncated if they exceed the buffer size. 

Writing High-Level Language Programs for the 29 80 

The high-level language application programmer must concern himself 
with the following fields of the DFHTCTTE structure when writing 
programs to run on a 2980 General Banking Terminal System: 

IIIL2 J3IAHNG 

TCTTETAB Number of tab characters (binary) 

TCTTEPCF Passbook control field 

TCTTESID Station identification 

TCTTETID Model U teller identification 

This section discusses one way to manipulate these fields. 

As discussed in the section "Passbook Control for the 2980", the 
application programmer is expected to read TCTTETA3 to determine the 
correct number of tab characters to place in his output data. The 
following examples show how this might be done in ANS COBOL and PL/I 
programs, respectively. 

1QT ANS COBOL: 

DATA DIVISION. 
WORKING-STORAGE SECTION. 
1 DFH2980 COPY DFH2980. 



LINKAGE SECTION. 

1 DFHBLLDS COPY DFH3LLDS. 

02 TCTTEAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 

02 TIOABAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 
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1 DFHTCTTE COPY DFHTCTTE. 

01 DFHTTOA COPY DFHTIOA. 
02 DATA PICTURE X(20). 

02 FILLER REDEFINES DATA. 

03 TAB 1-1 PICTURE X. 

03 DATA1 PICTURE X(19) . 
02 FILLER REDEFINES DATA. 

03 TAB1-2 PICTURE X. 

03 TAB2-2 PICTURE X. 

03 DATA2 PICTURE X(18), 



PROCEDURE DIVISION. 



IF TCTTETAB = TAB-ONE GO TO ONETBCH. 
IF TCTTETAB = TAB-TWO GO TO TWOTBCH. 



ONETBCH. 

MOVE TABCHAR TO TAB1-1. 
MOVE TOTAL TO DATA1. 



TWOTBCH. 

MOVE TABCHAR TO TAB 1-2, TAB2-2, 
MOVE TOTAL TO DATA2. 



2QT PL/T: 



^INCLUDE DFHTIOA; 

2 DATA CHAR (20) ; 
DECLARE 1 USERTIOA_1 BASED (TIOABAR) , 

2 TIOAFILL CHAR (12) , 

2 TAB1_1 CHAR (1) , 

2 DATA1 CHAR (19) ; 
DECLARE 1 USERTIOA_2 BASED (TIOABAR) , 

2 TIOAFILL CHAR (12) , 

2 TAB1_2 CHAR (1) , 

2 TAB2_2 CHAR (1) , 

2 DATA2 CHAR (18) ; 



"^INCLUDE DFH2980; 



IF (TCTTETAB = TABJDNE) THEN GO TO ONETBCH; 
TF (TCTTETAB = TAB_TWO) THEN GO TO TWOTBCH; 



ONETBCH: TAB1 1 = TABCHAR; 
DATAT = AMOUNT; 
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TWOTBCH: TAB1_2 = TABCHAB; 
TAB2_2 = TABCHAB; 
DATA2 = AMOUNT; 



In the ANS COBOL example, the structure DFH2980 is copied in the 
Working Storage Section; in the PI/I example, DFH2980 is included 
following the INCLUDE statements for the based structures. DFH2980 
contains constants that may be used when writing application programs 
for the 2980. 

The application programmer is also expected to test the TCTTEPCF 
field to determine whether there was a passbook present on a read or 
write. TCTTEPCR and TCTTEPCW are located in DFH2980 to aid in this 
testing. 

To test the TCTTEPCF field in ANS COBOL, statements such as the 
following might be used: 

MOVE TCTTEPCF TO HCLDPCF. 

IF HOLDPCFB = (HOLDPCFB / TCTTEPCW) * TCTTEPCW 

THEN GO TO BOOK-FOR-PRESENT-WRTTF. 

Substituting TCTTEPCB for TCTTEPCF allows the ANS COBOL programmer 

to test for the presence of a passbook on a read. (HOLDPCF and HOLDPCFB 

are also part of DFH2980.) 

To test the TCTTEPCF field in PL/I, statements such as the following 
might be used: 

IF (TCTTEPCF | TCTTEPCW) THEN GO TO 
BOCK-PBESENT-HBITE; 

Substituting TCTTEPCB for TCTTEPCF allows the PL/I programmer to test 
for the presence of a passbook on a read. 

To test the station identification and to determine whether the 
normal station or alternate station is being used, values are pre- 
defined in DFH2980 of the form: 

STATTON-#-A OB STATTON-#-N (for ANS COBOL) 

STATTON_#_A OR STATION_#_N (for PL/I) 

where # is any integer (0 through 9) and A and N signify alternate 
and normal stations. The values are one-byte character values and 
can be compared to TCTTESID in an IF statement. 

To test the teller identification on a 2980 Model 4, the TCTTETID 
field is defined as a one-byte character value; therefore it can also 
be tested in an IF statement. 

Twenty-three special characters are defined in DFH2980 that may 
he referenced by the name SPECCHAB-X (ANS COBOL and PL/I) where "X" 
is an integer (0 through 23) . Seven other characters are defined with 
names which imply their usage; for example, TABCHAB. For further 
information on these 30 characters, see Appendix E. 
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Following are the names defined in DFH2980 for ANS COBOL: 

STATTON-0-N STATION-6-A TAB-SIX MSGLITE SPECCHAR- 1 1 

STATION-0-A STATI0N-7-N TAB-SEVEN BCKSPACE SPECCHAR-12 

STATI0N-1-N STATION-7-A TAB-EIGHT TRNPGE SPECCHAR-13 

STATT0N-1-A STATION-8-N TAB-NINE SPECCHAR- 1 SPECCHAR- 14 

STATION-2-N STATION-8-A HOLDPCFB SPECCHAR-2 SPECCHAR- 15 

STATION-2-A STATI0N-9-N DFHFILL SPECCHAR-3 SPECCHAR-16 

STATION-3-N STATION- 9-A HOLDPCF SPECCHAR-4 SPECCHAR- 17 

STATION-3-A TAB-ZERO TCTTEPCR SPECCHAR-5 SPECCHAR-18 

STATION-4-N TAB-ONE TCTTEPCW SPECCHAR-6 SPECCHAR- 19 

STATION-4-A TAB-TWO TABCHAR SPECCHAR-7 SPECCHAR-20 

STATION-5-N TAB-THREE OPENCH SPECCHAR-8 SPECCHAR-21 

STATION-5-A TAB-FOUR JRNLCR SPECCHAR-9 SPECCHAR-22 

STATION-6-N TAB-FIVE PSBKCR SPECCHAR- 10 SPECCHAR-23 



Following are the names defined in DFH2980 for PL/Ir 



STATION N 


STATION 7 


_A 


TCCTEPCR 




SPECCHAR 7 SPECCHAR 22 


STATION 0~A 


STATION 8 


Jl 


TCTTEPCW 




SPECCHAR 8 SPECCHAR~*23 


STATION 1 N 


STATION 8 


"a 


TABCHAR 




SPECCHAR 9 


STATION.. 1 A 


STATION_9_ 


[n 


OPENCH 




SPECCHAR_10 


STATION 2 N 


STATION 9 


[a 


JRNLCR 




SPECCHAR 11 


STATION 2 A 


TAB ZERO 




PS3KCR 




SPECCHAR*" 12 


STATION 3 N 


TAB ONE 




MSGLITE 




SPECCHAR 13 


STATION 3 A 


TAB_TWO 




BCKSPACE 




SPECCHAR_14 


STATION 4 N 


TAB THREE 




TRNPGE 




SPECCHAR 15 


STATION 4 A 


TAB FOUR 




SPECCHAR, 


1 


SPECCHAR 16 


STATION_5~N 


TAB FIVE 




SPECCHAR* 


2 


SPECCHAR_17 


STATION 5 A 


TAB SIX 




SPECCHAR" 


3 


SPECCHAR_18 


STATION 6 N 


TAB SEVEN 




SPECCHAR" 


"4 


SPECCHAR~19 


STATION_6~[a 


TAB EIGHT 




SPECCHAR 


"5 


SPECCHAR~*20 


STATION 7~N 


TAB~NINE 




SPECCHAR" 


"6 


SPECCHAR 21 



7770 PROGRAMMING CONSIDERATIONS 

Even though CICS does not distinguish between any of the special 
codes (characters) that may be entered at an audio terminal (for 
example, the 2721 Portable Audio Terminal), an application program 
is not precluded from performing special functions upon encountering 
these codes. For example, the following special hexadecimal codes 
may be entered from a 2721 Portable Audio Terminal: 



KEY 



CODE 



CALL END 

CNCL 

# 

VERIFY 

RPT 

EXEC 

F1 

F2 

F3 

F4 

F5 

00 

000 

IDENT 



37** 

18 

3B** 

2D 

3D 

26** 

B1 

B2 

B3 

B4 

B5 

A0 

3B** 

11, 



or 7B 



or B0 
12, 13, or 14 plus two other characters 



For further information concerning the 2721, see the publication 
2721 Portable Audio Terminal Comp onen t. Descri ptio n (GA27-3029) . 
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The following special hexadecimal codes may be entered from a 
Touch-Tone* telephone: 

III CODE 

* AO 

* 3B** or BO 



trademark of the American Telephone S Telegraph Co. 

The * and # characters of a Touch-Tone telephone correspond to the 00 
and COO characters, respectively, on a 2721 Portable Audio Terminal. 

The above codes denoted by a double asterisk cause a hardware 
interrupt and are in the Terminal I/O Area (TIOA) immediately following 
the data; the codes are not included in the data length. 

Note: The # and 000 characters cause an EOI (X^B*) hardware interrupt 
unless the EOT Disable feature (#3540) is installed on the 7770 
Audio Response Unit Model 3. In this case, at the option of 
the user, either or both of the # and 000 characters do not 
cause a hardware interrupt and are presented in the TIOA along 
with the rest of data and are included in the data length. 

If, after receiving at least one character from a terminal, no other 
characters have been received by the 7770 for a period of five seconds, 
the 7770 automatically generates an "end of inguiry" (EOI) hardware 
interrupt that ends the read operation. 

CHEATING USER EXITS TOR ASYNCHRONOUS TRANSACTION PROCESSING 

If the Asynchronous Transaction Processing facility is used, the 
Input Processor (CRDR) and the Output Processor (CWTR) are employed 
to transfer data to and from CICS. The two programs accomplish the 
transfer of data without regard to its content. For example, any 
terminal-dependent characters in an output stream must have been put 
there by the user's transaction. 

However, it may be desirable to perfori some preprocessing or 
postprocessing on the terminal data. Such processing might be for 
purposes of: 

1. Validity and limit checking 

2. Removing or inserting device dependencies 

3. Summarizing or formatting 

4. Provide additional communication with CICS 

These and other services can be accomplished through the use of 
the user exits provided by CRDR and CWTR. During data input to CICS, 
CRDR offers each transmitted record to a user-written exit routine 
immediately after it is received. CWTR offers each record to a user- 
written exit routine immediately after it has been deblocked from its 
Transient Data input area. 

All records are made available to the user routine, including 
delimiter records. 

The exit routine is invoked by specifying its program name suffix 
in the CRDR or CWTR initiating the message. For example: 

CRDR EXIT=WD,NAME= WICHITA 
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causes CRDR to load the program named DFHXITMD (where DPHXIT is the 
standard exit routine base name and MD is the suffix) and pass each 
record to that routine while building a batch named WICHITA. 

Similarly, the statement: 

CWTR NAME=FINDLAY,TERMID* (TMLA,TMLB,TMLC) , EXIT=DI 

causes CWTR to load the program DFHXITDT and pass each output record 
(associated with the output of batch FINDLAY) to the routine before 
it is transmitted to the terminal. 

One additional point should be noted concerning records given to 
the CWTR exit routine. The messages being sent in response to a STATUS 
reguest are passed to the routine. For example: 

CWTR NAME=SUNYVALE, STATUS, EXIT=CN 

causes the message concerning the status of a batch named SUNYVALE 
to be passed to DFHXITCN. This permits the user-written exit routine 
to augment the status message. All CICS service macro instructions 
may be used in the exit programs. 

CODING THE CRDR EXIT ROUTINE 

The CRDR Input Processor uses the following basic TCA work area 
definitions: 

OPY DFHTCADS 

Address of record to be inserted 

Address of user work area 

Indicators 

Exit program return indicator 

Reserved 

Reserved 

These fields (plus any additional fields) should be defined by the 
user-written exit routine within the limits specified in the PCT entry. 
Information is passed between CRDR and the exit routine by means of 
this TCA work area. 

Upon initial entry to the exit routine TWAWA and the TWAXTRTN bit 
are zero. On all entries, TWAREC is zero. All modification of the 
TWAXTRTN bit must be done either by the instruction 01 TWAIND, TWAXTRTN 
or the instruction NI TWAIND, 255-TWAXTRTN. The user exit must take 
care not to modify the bits in the TWAIND field used by CWTR. 

On all entries to the exit routine, register contents are: 

REGISTER CONTENTS 





COPY 


DFHTCADS 


TWAREC 


DS 


A 


TWAWA 


DS 


A 


TWAIND 


DS 


X 


TWAXTRTN 


EQU 


X»80» 




DS 


3X 




DS 


2 OF 



15 
14 
13 
12 

8 

7 



Exit routine entry address 

Exit routine return address 

CSA address 

TCA address 

TIOA address of last message read 

BCA address 



The only registers that cannot be used in the routine are registers 
12 and 13. The other registers are saved before exiting and are 
restored by CRDR upon return. The Batch Control Area (BCA) is described 
in the symbolic storage definition named DFHBCADS. 
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The exit routine must be enterable at two points. The first entry 
is for routine initialization and is made via an Assembler BALB 14,15 
instruction. This is done only once so that turning on> the TWAXTBTN 
bit does not cause a reentry to occur. The message in the TIOA is 
the CRDR transaction-invoking message. 

All subsequent entries to the exit routine are made via an Assembler 
BAL 14,4(15) instruction. This entry is made after each message is 
read. 

The exit routine entry coding might appear as follows: 



FAB 


CSECT 






USING 


*,15 




B 


INIT 




B 


MSGP 




DROP 


15 




USING 


DFHXITAB,10 



INIT 



MSGP 



LB 



IB 



10,15 



10,15 



If the record just read is to be accepted without change or is to 
have its contents altered, it can be done in the TIO& and return made 
to CRDB via a BR 14 instruction. TWAREC and the TWAXTRTN bit should 
remain zero. 

Tf the length of the record just read is to be changed, it can be 
done in the TIOA by altering the TIOATDL field. TWAREC and the TWAXTRTN 
bit should be zero. If the record is to be lengthened such that it 
won't fit in the TIOA, the record must be built in a user-defined work 
area as a standard variable-length record. fThe record in the TIOA 
is not a standard VLR since the value in TIOATDL is four less than 
a VLR count.) The address of the count field (LLbb) is then put into 
TWAREC and control is returned to CRDR. 

When the exit routine once again gains control, TWAREC is zero and 
a new message is in the TIOA. A work area used to alter records may 
ce defined in the TCA work area or acquired dynamically through use 
of a CICS DEHSC TYPE=GETMAIN macro instruction. If acquired 
dynamically, its address may be stored at TWAWA. 



To insert records into the 
built in an exit routine work 
TWAXTBTN bit set on, and cont 
is inserted and control is re 
set to zero and the TWAXTRTN 
have been inserted in this ma 
zero and control returned to 
original message in the TIOA 
new message is read from the 



input stream, each new record must be 
area, its address placed at TWABEC, the 
rol returned to CBDB. The new record 
turned to the exit routine with TWABEC 
bit left unchanged. After all new records 
nner, the TWAXTBTN bit must be set to 
CBDB with TWABEC containing zero. The 
is placed into the input stream and a 
terminal. 



If the original message in the TIOA is to be deleted, control must 
be returned to CBDR with TWABEC containing the address of F'0». 
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CODING THE CWTR EXIT ROUTINE 

The CWTR Output Processor uses the following basic TCA work area 
definitions: 





COPY 


DFHTCADS 


TWANXREC 


DS 


A 


TWAREC 


DS 


A 


TWAWA 


DS 


A 


TWAIND 


DS 


X 


TWAXTRTN 


EQU 


X»80' 




DS 


3X 




DS 


30F 



These fields (plus any additional fields) should be defined by the 
user-written exit routine within the limits specified in the PCT entry. 
Information is passed between CWTR and the exit routine by means of 
the TCA work area. 

Upon initial entry to the exit routine, TWAWA and the TWAXTRTN bit 
are zero. On all entries TWAREC is zero, and TWANXREC points to the 
variable-length record which is to be transmitted to the output 
terminal. Any modification of the TWAXTRTN bit must be done on a bit 
level since other bits in TWAIND are used by CWTR. 

The first four bytes of a variable-length record contain a two-byte 
length field and, occasionally, two bytes of control information. 
In the case of the record to be handled by CWTR, the first of these 
two control bytes (byte three of the record) contains the byte that 
would ordinarily be moved to TCTTEOS by the DEHTC macro instruction. 
The second control byte (byte four of the record) applies only to 
records that are destined for a 2260 Display Station or a 3270 
Information Display System; this control byte corresponds to the TIOALAC 
or TIOACLCR field. If the destination terminal is a 3270 and the 
TIOACLCR field is not applicable, X'CS 1 (the default value) must be 
moved into this control byte. 

If the length of the record is to be changed, the two control bytes 
probably are not affected and the information from the original record 
can be used. However, building a new record reguires that one or both 
of these control bytes be properly constructed. 

On all entries to the exit routine, register contents are: 

REGISTER CONTENTS 

15 Exit routine entry address 

14 Exit routine return address 

13 CSA address 

12 TCA address 

7 BCA address 

The only registers that cannot be used in the routine are registers 
12 and 13. The other registers are saved before exiting and restored 
by CWTR upon return. 

The exit routine must be enterable at two points. The first entry 
is for routine initialization and is made via an Assembler BALR 14,15 
instruction. This is done only once so that turning on the TWAXTRTN 
bit does not cause a reentry to occur. Also, there is no message 
located by TWANXREC. 

Ail subsequent entries to the exit routine are made via an Assembler 
BAL 14,4(15) instruction. This entry is made after each message is 
deblocked and is about to be transmitted. 
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The exit routine entry coding might appear as follows: 



DEHXITA3 


CSECT 






USING 


*,15 




B 


INIT 




B 


MSGP 




DBOP 


15 




USING 


DFHXITAB,10 



INIT 



MSGP 



LR 



LR 



10,15 



10,15 



If the record about to be written is to be accepted without change 
or is to have only its contents altered, it can be done in its current 
area located by TWANXREC. Return to CWTR is made with a BR 1 4 
instruction; TWAREC and the TWAXTRTN bit should be zero. 

If the length of the record is to be altered, it must be done by 
replacing the record located by TWANXREC with the altered record. 
The altered record must be built in an exit routine work area as a 
standard variable-length record. The address of the new record must 
be put into TWAREC and control returned to CWTR. The new, altered 
record replaces the old record. When the exit routine once again gains 
control, TWAREC is zero and a new message is located by TWANXREC. 

If the new record just described is to be inserted into the output 
stream in addition to the record at TWANXBEC, the TWAXTRTN bit must 
be set to one prior to returning to CWTR. The new record (pointed 
to by TWAREC) is sent to the terminal and control is returned to the 
exit routine with TWANXREC pointing to the original record; TWAREC 
is zero. This permits the exit routine to continue inserting records 
into the output stream until return to CWTR is made with the TWAXTRTN 
tit and TWAREC set to zero. 

Deleting a record can be done by returning control to CWTR with 
TWAREC containing the address of F'O*. 

If dynamic storage is reguired by the exit routine, it can be 
acguired from Storage Control and saved by putting its address in 
TWAWA. 

DATA BASE CONSIDERATIONS 

SEGMENTED RECORDS 

An optional feature of CICS File Management allows the user to 
create and define a data set containing segmented records. A segmented 
record is one in which the components of the record have been identified 
(symbolically) and grouped according to some logical relationship such 
as function or frequency of use. 

The identifiable groups are called segments. A segment is one or 
more adjacent fields within a record. Some segments appear in all 
records (for example, those segments containing identification or major 
record control fields) , while other segments apply only to, and appear 
in, certain records. Before the application programmer can use 
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segmented records in his program, the structure and individual segments 
of a segmented data set must have been previously defined by the user 
in the File Control Table. 



Segmented records offe 
defined the segments of a 
sets and retrieve any set 
identifying that set. Si 
of any number of segment 
flexibility in the retrie 
set) of a logical record 
reguested segments, pass 
main storage reguired for 
earliest possible time. 



r numerous advantages. Having organized and 
data set, the user can group them into segment 
(or group) of segments by symbolically 
nee an individual segment can be a member 
sets, the user gains a high degree of 
val process. Because only a part (a segment 
is reguested, CICS can extract just the 
them to the processing program, and free the 
the entire logical record or block at the 



A saving in DASD space can be realized when segmenting is used with 
variable-length record format, since CICS File Management always 
compresses (packs) a segmented record before writing it to direct 
access. The space normally reguired for missing segments is thus 
eliminated, as are the slack bytes created when aligning segments in 
main storage. 

With fixed-length records, compression causes the unused space to 
te consolidated at the end of the record. For example: 

* Logical record as defined by the user in the File Control Table 



ROOT 



SEG2 SEG3 



SEG4 SEG5 



SEG6 



• Logical record as it appears on DASD with missing segments 
ROOT SEG3 I SEG5 | SLACK BYTES! 



The following general rules apply to the use of segmented records: 



1. Segmented rec 
data sets. 

2. Segmented rec 
fixed, fixed 
advantageous 

3. A data set th 
index data se 
CICS features 
However, the 
hierarchy may 

4. Every segment 
it actually e 
the File Cont 



ords can be used with either ISAM or DAM organized 

ords can be used with any record format (that is, 
blocked, variable, undefined) but are primarily 
with variable-length records. 

at contains segmented records may not also be an 
t in an indirect accessing hierarchy. The two 

are mutually exclusive for any one data set. 
primary (target) data set in an indirect accessing 

contain segmented records. 

that could appear in a record, whether or not 
xists in a particular record, must be defined in 
rol Table. 



Searaented Record Fo rm ats 

It is the user's responsibility to describe, for each segmented 
data set, all segments within a logical record. Each segmented data 
set is first described in the File Control Table just as any other 
data set. That is, its basic characteristics must be described so 
that CICS File Management can physically access it (for example, block 
size, logical record length, key length, etc.). As an addendum to 
this basic data set descriptive section, the user must describe the 
segmented structure of the data set. 

Every segment (any number of adjacent bytes up to a maximum of 255) 
must be defined, even if it does not exist in every logical record. 
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While it is not required that every logical record contain every 
segment, every logical record must contain at least the root (control) 
segment. 

The root segment is a uniquely defined segment that must appear 
at the beginning of each logical record. Tt contains as a minimum: 

1. The length of the record, if variable-length records are being 
used. This is a fullword (four bytes) of the form LLbb, where 
LL is the record length and bb is two bytes reserved for system 
use. 

2. Segment indicators, which indicate the presence or absence of 
each segment in the record* Segment indicators are discussed 
in greater detail below. 

Tn addition, the 'root segment could contain any other information 
that might aid in the processing of the record by the user (for example, 
a major control field such as an account number) . 

The following is an example of a segmented record and the root 
(control) segment. 

LOGICAL RECORD 



CONTROL SEGMENT 


SEGMENT 2 


SEGMENT 3 


SEGMENT H 



SEGMENT , ~~ , 

LLbb \ ACC^ NUM | INDICATORS | OTHER CONTROL INFO [ 

The sequence of the segments within a logical record must be fixed. 
That is, a segment may not change position in relation to the other 
segments of the record. Each segment can be fixed or variable in 
length. If the segment is variable in length, then the first byte 
must contain the length, in binary, of the segment, not including the 
length byte. Thus the maximum data length of a variable-length segment 
is 254 bytes instead of 255. The number of bytes in a fixed-length 
segment or the maximum length of a variable-length segment is supplied 
to CTCS File Management as part of the segment definitions in the File 
Control Table. 

Each segment has its own characteristics and these can be different 
from other segment definitions. Each segment can have a different 
length than other segments, and, if defined as variable length, can 
change as a result of an update. Segments may be added or deleted; 
CICS File Management compresses and expands the record accordingly. 

CICS File Management provides for the user to specify the alignment 
requirements of each segment when that segment is brought into main 
storage. This alignment may be on a one-byte, two-byte, four-byte, 
or eight-byte boundary. The default alignment is on a one-byte 
boundary. When the segmented record is written to direct access, any 
residual space (slack bytes) caused by alignment is eliminated by CICS 
"""ile Management through the compress (packing) function. 

Segment Indicators 

Segment indicators are the means by which CICS File Management and 
the processing program specify, and determine, the presence or absence 
of specific segments within a logical record. There are two types 
of indicators available to the user; it is his responsibility to choose 
the type he wishes to use and to define his data sets accordingly. 
Regardless of the type of indicator, the following general rules apply 
to the use of segment indicators in processing the segmented record: 
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1. Segment indicators are always located in contiguous bytes within 
the root (control) segment. Note that every logical record 
contains a root segment and that the root segment is always 

a part of any segment set brought into main storage. Therefore, 
the segment indicators are always accessible to the user. 

2. The location of the indicators within the root segment is defined 
by the user in the File Control Table as being some displacement 
from the beginning of the root segment. 

3. There must be one indicator for each segment which is defined, 
other than the root segment. The position of the indicator 
determines which segment it represents. Since the root segment 
does not reguire an indicator, the first indicator represents 
the first segment following the root segment (segment 2) , the 
second indicator represents the second segment following the 
root segment (segment 3) , etc. 

U. When retrieving segment sets, it is the user's responsibility 
to test the appropriate indicator to determine if a specific 
segment is present. He should never assume a segment is present 
simply because it was reguested as part of a segment set. 

5. When adding or deleting segments from a record, it is the user's 
responsibility to reset the appropriate indicator to reflect 
the change. 

BIT TYPE SEGMENT INDICATORS: With the bit type indicator, each segment 
is represented by a bit position in the segment indicator field. One 
byte of indicators must be provided within the root segment for each 
eight segments in the logical record. If a given bit indicator is 
en (binary 1) , the corresponding segment is present in the logical 
record. 

If a given bit indicator is off (binary 0) , the corresponding segment 
is absent from the logical record. The following are examples of bit 
type segment indicators: 



FIXED LENGTH |rOOT (CONTBOL) SEGMENT \+ DATA SEGMENTS 

SEGMENTS 

) |l 11 10000 | ) SEG2 | SEG3 { SEG4 | SEG5 | 

1 Byte of 

Bit Indicators 



VARIABLE 

LENGTH 

SEGMENTS 

FIXED IsMGTH 
SEGMENTS 

MISSING 
SEGMENT 



{BOOT SEGMENT - 

I |imoooo 



BOOT SEGMENT - 
I1011C000 



DATA SEGMENTS 



|l| SEG2|L|SEG3|L| SEG4 |l|SEG5| 



m DATA SEGMENTS 

SEG2 I SEG4 I SEG5 



SLACK 



DISPLACEMENT TYPE 
indicator, each s 
in the segment in 
value of zero ind 
logical record, 
indicates that th 
the displacement 
record when the s 



SEGMENT INDICATORS: With the displacement type 
egment is represented by one halfword (two-bytes) 
dicator field. In any given halfword indicator, a 
icates the corresponding segment is absent from the 
A nonzero value (binary) in any given halfword 
e corresponding segment is present and represents 
of the segment from the beginning of the logical 
egments are packed. 



Any displacement value which is placed in the halfword indicators 
when building a new record or adding and deleting segments from an 



172 



existing record, may be modified by CICS File Management when it 
compresses (packs) the segments before writing the record to direct 
access. Whenever CICS packs segmented records, it places the 
displacement value of each segment into the corresponding halfword 
indicator (if displacement type indicators are being used) . However, 
CICS File Management does not change these displacement values when 
unpacking a segmented record or when extracting selected segments of 
a segment set. 

The user should not rely on the displacement values in order to 
access segments he has retrieved in a segment set; he should only use 
them as zero/nonzero indicators to determine whether or not a reguested 
segment is present. (See "Main Storage Processing of Segmented 
Records" .) 

The following example illustrates the basic concepts and 
considerations when using displacement type segment indicators. 

1. The following is the segmented record built by the user in main 
storage which is to be added to a segmented data set: 



20 BYTES 10 BYTES 8 BYTES 8 BYTES 5 BYTES 



CONTROL 
INFORMATION 



EMPTY 



DATA 



DATA I DATA 

ROOT SEGM ENTS SEG MENT2 SEGMENT3 SEGMENTS SEGMENT5 
2 BYTES 



The user has placed data in three of the four defined segments 
and indicated their presence by placing a nonzero value in the 
corresponding halfword displacement indicators. Any nonzero 
value may be used (the 1 is only an example) . 

Before writing the record to the direct access data set, CICS 
File Management compresses the segments and' modifies the 
displacement indicators so that the above record would appear 
as follows before being written to DASD: 



20 BYTES 10 BYTES 8 BYTES 5 BYTES 



8 BYTES 



CONTROL 
INFORMATION 


20 


30 





38 


DATA 


DATA 


DATA 


EMPTY 



ROOT 
SEGMENT 



SEGMENT2 



SEGMENT3 SEGMENT5 



When retrieving a segment set from the above record, the root 
segment is included as part of the segment set without any 
modification. If the user were to reguest a segment set from 
the above record (consisting of the Root Segment and Segment3) , 
the data he would receive might appear as follows: 



CONTROL 
INFORMATION 



20 



30 







38 



I 8 BYTES- 
DATA 



ROOT SEGMENT 



SEGMENT3 



173 



Jlain Storage Processing Of Segmented Records 

When a segment set is requested from a segmented data set, the data 
is always placed into a File Work Area (FWA) . The length of this FWA 
is variable depending upon the segments retrieved and their attributes. 
However, it is not the users responsibility to determine this length 
since CICS File Management automatically calculates it and acguires 
the FWA through CICS Storage Management. A ClCS-provided symbolic 
storage definition (DFHFWADS) can be used in conjunction with a user- 
defined layout to map the FWA. 

The FWA consists of control fields (used by CICS Management 
functions) and a data area into which the requested segments are placed 
by File Management. The format of the retrieved segments within the 
data portion of the FWA is always in a fixed format. That is, space 
is provided in the FWA and alignment requirements are met for each 
segment in the requested segment set, even though a segment may be 
missing. (For variable-length segments, the maximum space is provided.) 
It is the user's responsibility to test the appropriate segment 
indicators to determine the presence or absence of a segment. Note 
that an update request on a segmented data set causes CICS File 
Management to automatically use the universal segment set "ALL" when 
retrieving the record. 

The following illustrations should help clarify the various 
considerations discussed thus far concerning main storage processing 
of segmented records. 

1. Logical record as defined by the user in the File Control Table: 

| ROOTSEG | SEG2 | SEG3 | SEG4 | SEG5 [ SEG6 | SEG7 | SEG8 | SEG9 | 

2. Logical record as it appears on DASD. Assume variable-length 
records and bit type segment indicators: 



LLbb 



11010100 



SEG2 



SEG3 



SEG5 



SEG7 



ROOT SEGMENT 



Logical record as it appears in the FWA after retrieval of a 
segment set (read-only) which included Root Segment, SEG2, SEG6, 
SEG7, SEG8: 

FWA CONTROL 

FIELDS | XLBB j 1 10 1 0100 | DATA JEMPTYJ DATAJ EMPTY ) 
ROOT SEGMENT SEG2 SEG6 SEG7 SEG8 



Logical record as it appears in the FWA after a retrieval for 
update (SEGSET=ALL) : 



FWA CONTROL 

FIELDS llLBBhlOl 0100 IdATAIdATaI 



DATAl 



Idata 



ROOT SEGMENT 



SEG2 SEG3 SEG4 SEG5 SEG6 SEG7 SEG8 SEG9 



Logical record as it appears in the FWA after the user has added 
segments H and 8 and deleted segment 3. The indicators have 
been adjusted by the user to reflect the change. 



FWA CONTROL 

FIELDS |LIBB|l011 0110 I DATAl I DATAJ DATAl IdATAIdATAI 



ROOT SEGMENT 



SEG2 SEG3 SEG4 SEG5 SEG6 SEG7 SEG8 SEG9 
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6. Logical record as it appears on DASD after packing: 

| Ilbb |.1011 0110 j DATA |DATa1pATa1pATA| DATAJ 
BOOT SEGMENT SEG2 SEGU SEG5 SEG7 SEG8 

Se gmen t Sets 

Once each segment has been defined (name and attributes specified) , 
the user can specify as many segment sets as he desires. A segment 
set is a grouping of the root segment and at least one or more 
individual segments. Like the individual segments, the segment set 
is given a symbolic name which is used by the application program when 
processing a segmented data set. Any retrieval from a segmented data 
set is always by segment set. 

Assume a logical record in a segmented data set has been defined 
as containing the following symbolic segments: 

BOOTSEG 

SEGMENT2 

SEGMENT3 

SEGMENTU 

SEGMENT5 

SEGMENT6 

The user might wish to define the following segment sets: 

SEGMENT SET NAME SEGMENTS 

SEGSETA BOOTSEG 

SEGMENT2 
SEGMENTS 

' SEGSETB BOOTSEG 

SEGMENT3 
SEGMENTS 
SEGMENTS 

Whenever a segmented data set is defined in the File Control Table, 
a universal segment set is automatically generated which includes all 
segments defined for that data set. The symbolic identification of 
this universal segment set is "ALL", and is automatically used by CICS 
File Management whenever the application program reguests a "read for 
update" from a segmented data set. In other words, an update operation 
on a segmented data set always causes all segments to be presented 
to the user, regardless of the segment set specified by the user. 

INDTBECT ACCESSING 

Indirect accessing, an optional data base feature in CICS, provides 
for the use of cross-index data sets to access another data set. The 
data set that is accessed by an index data set is known as the "primary" 
or "target" data set. This feature allows the user to furnish the 
search argument for an index data set along with the identification 
of the primary data set. CICS, utilizing the user-defined index 
structure, carries out the search, involving as many levels (index 
data sets) as defined by the user, and ultimately retrieves the prime 
data required. 

The following general rules apply to the Indirect Accessing feature: 
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1. A primary data set can have any number of index data sets. 

This is useful when multiple cross references to a master record 
exist. 

2. Any data set can be both an index and a primary data set. The 
logical record content of any data base data set is user-defined 
and constructed, and therefore may contain certain master record 
information as well as a search argument for another data set. 

3. There is no logical limit to the number of index levels (data 
sets) that the user may define in an index hierarchy. For 
example, data set A is an index to data set B which is an index 
to data set C which is an index to data set D, etc. 

4. An indirect access hierarchy can be any combination of ISAM 
and DAM data sets. 

5. an index data set may not also contain segmented records. The 
two CICS services are mutually exclusive for any one data set. 
However, a primary data set, which an index data set accesses, 
could have segmented records if it were not defined also as 

an index data set. 

6. An index data set cannot reference more than one primary data 
set unless the index data set is multiply defined in the File 
Control Table. 

7. If the index data set is a DAM data set, it may not be defined 
as blocked. However, the primary data set may be defined as 
blocked BDAM. 



The following is an example of a sim 
hierarchy. The retrieval search begins 
The primary data set being accessed (an 
returned to the reguesting program) is 
to be used in accessing the index data 
contents of the record located by the s 
(CATLOG#) contains the search argument 
f or search of PARTNO) . The primary dat 
the data record returned to the reguest 



pie two-level indirect access 

with the index data set CATLOG# 
d from which data is to be 
PARTNO. The search argument 
set (CATLOG#) is CN222. The 
earch of the index data set 
for the next data set (12345 
a set (PARTNO) is searched and 
ing program. 



TRANSACTION 

PROCESSING 

PROGRAM 

DFHFC TYPE=GET, 

INDEX=CATIOG#, 

DATASET=PARTNO, 

RDIDADR= 



CATLOG# 



PARTNO 




It is the user*s responsibility to create and maintain all data 
sets in his data base, and to define all data sets (both index and 
primary) in the File Control Table. Each data set, whether it is an 
index and/or primary data set, is first described as a primary data 
set in the File Control Table. That is, its basic physical 
characteristics must be defined so that CICS File Management may access 
it (for example, BLKSIZE, LRECL, KEYLEN, etc) . If the data set is 
to be further used as an indirect access data set, it must also be 
defined with the following information: 

1. The primary data set for which this data set is an index. 
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2. The location of the search argument, within the logical record 
of this data set, to be used for accessing the primary data 
set (or the next index data set) . 

If the user creates and properly defines an index hierarchy for 
indirect accessing, CICS File Management -will service any request 
requiring use of that hierarchy, provided the requesting application 
program adheres to the following general rules and considerations: 

1. The symbolic name of the first index data set to be searched 
in the retrieval process must be specified through the INDEX 
operand of the DFHfC macro instruction. This data set can be 
any index data set in a hierarchy of indexes, not necessarily 
the highest level index data set. It can also be the primary 
data set being accessed without the use of an index data set. 
However, in the latter case, the DATASET operand must be used 
instead of the INDEX operand. 

2. The symbolic name of the primary data set from which data is 

to be ultimately retrieved and returned to the requesting program 
must be specified through the DATASET operand of the DFHFC macro 
instruction. Any number of intervening data sets can be used 
in the search; however, the user specifies only the first and 
the last data set. It is possible for the user to limit a 
search to only a portion of an index hierarchy; that is, it 
is not necessary to search an entire index hierarchy. 

3. The search argument to be used by CICS File Management to access 
the first referenced data set must be specified through the 
RDIDADR operand of the DFHFC macro instruction. This search 
argument is either an ISAM key or a DAM Record Identification 
Field. If multiple levels of index data sets are involved, 
CICS File Management acquires a search argument for the next 
data set from the logical record of each successive data set. 

When stepping through a series of index data sets, CICS File 
Management uses the requesting program's Record Identification field 
(specified in the RDIDADR operand) to store the search argument for 
each successive data set to be searched. It is the user's 
responsibility to ensure that this field is as large as the largest 
search argument that will be used in any given retrieval operation. 

^he following is an example of the above consideration in a three- 
level indirect accessing hierarchy. The search argument provided by 
the processing program is used to access the first index data set 
(CA^LOG*) that provides the search argument for a second index data 
set (PARTNO) that provides the search argument for the primary data 
set (VENDOR) from which the data record is retrieved and returned to 
the user. Since the search argument retrieved from the second index 
data set (PARTNO) is eight bytes in length (V00C0996) , the user's 
Record Identification field (RDIDADR) must be at least eight bytes 
in length even though it initially contains only the five-byte search 
argument (CN222) for the first index data set. 



TRANSACTION PROCESSING 
PROGRAM 



DFHFC TYPE=GET, 

INDEX=CATLOG#, 

DATASET=VENDOR, 

RDTDADR=-- ) 

|CN222^ ' 




CATLOG* 



Il2345l 



PARTNO 



VENDOR 



VQQQQ996I 



177 



DUPLICATE RECORDS 

An optional feature of the indirect accessing approach to data base 
retrieval is the capability to indicate that a search argument in an 
index data set, which would normally reference the primary data set, 
instead references a "duplicates" data set. The need for or use of 
duplicates data sets may best be described as follows. 

Assume that the application program reguires access to an index 
data set organized by street address to obtain the name of the occupant 
at that address. The occupant's name is then used to access a primary 
data set organized by name. 

For single occupancy, no problem exists. However, for multiple 
occupants, the index data set cannot directly eguate a street address 
to a primary data set record. Instead, the search argument field in 
the index record indicates that multiple occupants (duplicates) exist 
and that the search argument provided references a duplicates data 
set rather than the primary data set. 

CICS Pile Management retrieves the referenced record from the 
duplicates data set and returns it to the application program with 
a response code indicating a duplicates record. The duplicates record 
may contain further information, which the application program can 
use to more accurately retrieve a reguested master record. 

If an index data set is to indicate that there can be duplicate 
keys for entries in the primary data set that it references, the user 
must have previously included the necessary information in the File 
Control Table entry which describes the index data set. The index 
data set record must contain in the first byte of the search argument 
field a unigue one-byte duplicates indicator (user-defined) . Care 
must be taken to ensure that this indicator is a unigue code, which 
cannot be the same as the first byte of a normal search argument for 
the primary data set. 

The rest of the search argument field contains the search argument 
used by File Management to retrieve a record from the duplicates data 
set. This record has user-defined and user-constructed information 
that the application program can use to select the appropriate primary 
data set record. The following is an example of a search argument 
field in an index record that reflects duplicates: 



DUPL 
IND 



SEARCH ARGUMENT FOR 
DUPLICATES RECORD 



OR 
SEARCH ARGUMENT FOR 
NEXT LEVEL OF INDEX 



The search argument for the duplicates data set must meet the same 
search argument format reguirements as those for a normal cross-index 
data set. Note that the length of the search argument used to access 
a duplicates data set is one byte smaller because of the duplicates 
indicator. 

The following is an example of an index hierarchy with a duplicates 
data set. The application program begins the retrieval by accessing 
the index data set (PARTNAM) and ultimately accesses the primary data 
set (PARTNO) . The search argument (GTSMO) provided by the application 
program is a valid one for the index data set (PARTNAM) , but it provides 
a record containing a duplicates flag. 
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When the duplicate indicator is detected, CICS File Management uses 
the new search argument (from the PARTNAM data set) to access the 
duplicates data set (DUPLNAM) , returning the duplicates record to the 
application program. 

In this example, the part name (GISMO) is not unique since there 
are several types of GISMO' s in the part number (PARTNO) data set. 
The requesting program must provide more qualifying data concerning 
which GISMO is desired. 



TRANSACTION PROCESSING 
PROGRAM 



PARTNAM 



PARTNO 



DFHFC TYPE=GET, 

TNDEX=PARTNAM, 
DATASET=PARTNO 
RDIDADR= 




The record retrieved from the duplicates data set in the example 
might appear as follows: 

I GISMO 1 LARGE [9123 I MED [ 9872 I SMALL [ 9944 



PARTNAM DESC 



PARTNO 



DESC 



PARTNO 



DESC 



PARTNO 



The application program might formulate a message to be routed to the 
inquiring terminal asking the terminal operator to make a choice. 
For example: 



PART NAME REQUESTED HAS MULTIPLE ENTRIES 
PLEASE SELECT SPECIFIC PART NUMBER 

PART NAME DESCRIP PART NUMBER 
GISMO LARGE 9123 

MED 0872 

SMALL 9944 



Once the terminal operator has made a selection, the processing 
program can make a direct retrieval from the primary (PARTNO) data 
set. 

Note that if the index record in the above example had not contained 
a duplicates indicator, CICS File Management would have used the search 
argument to access the primary data set (PARTNO) and retrieve the 
requested data. 
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I AVI DATA SET CONSIDERATIONS 

S§cor d Identification Fiel d 

The Record Identification field is the means by which the application 
program communicates to CICS Pile Control the identity of the specific 
record which is being sought. (See the discussion of the RDIDADR 
operand as it applies to the DFHFC macro instruction.) For ISAM 
organi2ed data sets, this field is relatively simple in structure since 
it contains only the key of the logical record. However, for DAM 
organized data sets the Record Identification field structure is a 
bit more complex, since it is necessary for the application program 
to supply the block reference information, physical key (if keyed data 
sets are being used) , and the deblocking argument (if blocked data 
sets are being used) . 

Note: If more than one browse operation or update operation is to 
be concurrently performed by a single application program, a 
unigue Record Identification field must exist for each operation. 

The Record Identification field for DAM data sets is really a 
concatenation of three subfields, identified as follows: 

1. Block reference 

The physical identifier of the DAM block, is specified by the 
RELTYPE operand of the File Control Table and may be one of 
the following: 

a. Relative Block (CICS/OS only) three-byte binary (RELTYPE=BLK) 

b. Relative Track and Record - two-byte TT, one-byte R 
(RELTYPE=HEX) 

c. Relative Track and Record (zoned decimal format) six-byte 
TTTTTT, two-byte RR (RELTYPE=DEC) 

d. Actual address - eight-byte MBBCCHHR (RELTYPE omitted) 

EXAMPLE 



Relative block (OS only) 
(binary) 

Relative track and record 

Relative track and record 
(zoned decimal) 

Actual 



BYTE 





1 


2 3 


l\ 


5 


6 


7 


8 




RELBIK #| 


T 


T 


R 


■I 






T 


T 


* I 






T 


T 


T T 






M 


B 


B C 


C 


H 


H 


•I 





2. Physical key 

The physical key is reguired only if the data set being accessed 
is written with recorded keys. This key must be the same length 
as specified in the BLKKEYL parameter for the File Control Table 
(FCT) entry which defines the data set. It must immediately 
follow the block reference information, which can be any of 
the above. 



180 



EXAMPLE 



BYTE 


1 2 


3 a 


5 6 7 


3 . . 




RELBLK* 


KEY... 


(CICS/OS < 


snly) 




T T R 


KEY... 




ffl TTI 111 fp fp 


T R R 


KEY... 




H B B C C 


H H R 


KEY . . . 













3. Deblocking argument 

The deblocking argument is require 
blocked records and the user wishe 
from within a block. It is not ma 
every physical record; he may wish 
The deblocking argument may be eit 
number. The user's choice is spec 
of the DEHFC macro instruction. I 
argument must immediately follow t 
or the block reference (if the phy 



d only if the data set contains 
s to retrieve a logical record 
ndatory that the user deblock 
to retrieve the entire block, 
her a key or a relative record 
ified in the RETMETH operand 
f present, the deblocking 
he physical key (if present) 
sical key is not present) . 



If the deblocking argument is a key, it must be the same length 
as specified in the KEYLEN parameter of the File Control Table 
(FCT) entry which describes the data set. Mote that the key 
used for deblocking need not be the same size as the physical 
record key (B1KKEY1) . If the deblocking argument is relative 
record number, it is represented by a one-byte binary number, 
with a value of zero representing the first logical record of 
a block. 

EXAMPLE (physical key - 6 bytes, deblocking key = 3 bytes) 

BYTE 12 3 4 5 6 7 8 9 10 1 1 12 13 14 15 



RELBLK | RN [ (CICS/OS only) 



Search By Relative Block 
Deblock By Relative Record 



RELBLK [ KEy( (CICS/OS only) Search By Relative Block 

Deblock By Key 



T R 



KEY 



M B B 



H H R RN 



KEY I Search By Relative Track 
Key, Deblock By Key 

Search by Actual ID 
Deblock By Relative Record 



KEY 



KEY 



KEY 



Search By Zoned TTR 5 Key 
Deblock By Key 

Search By Relative Track S 
Record, Deblock by Key 



Adding Re cords to DAM Data Sets 

When adding new records to DAM data sets, the application programmer 
should be aware of the following considerations and restrictions: 

1. The addition of undefined or variable-length records (keyed 

or non-keyed) requires the user to indicate the track on which 
the new record is to be added. If space is available on the 
track, the new record is written following the last previously 
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written record, and the record number is placed in the "B" 
portion of the user's Record Identification field. The track 
specification may be in any of the acceptable formats except 
relative block. If zoned decimal relative format is used, the 
record number is returned as a two-byte zoned decimal number 
in the seventh and eighth positions of the Record Identification 
field. 

Tn the CICS/DOS system, an attempt to add a variable-length 
or undefined record is limited to the single track specified 
by the user. If not enough space is available on that track, 
a "no space available" error is returned to the user who may 
then try to add the record on another track* Under these 
circumstances, the record is returned by the user in an FWA, 
the address of which is at TCAFCAA. The user need only modify 
the track identification and issue another DFHFC TYPS=PUT, 
TYPEOPR=NEWREC macro instruction to add the record on another 
track. 

In the CICS/OS system, the extended search option allows the 
record to be automatically added to another track if no space 
is available on the specified track. Under these circumstances, 
the location at which the record was added is returned to the 
user. 

The addition of keyed fixed-length records to DAM data sets 
reguires that the data set first be formatted with dummy records 
or "slots" into which new records may be added. (A dummy record 
is signified by a key of hexadecimal 'FF's; in CICS/OS, the 
first byte of data contains the record number.) 

For non-keyed, fixed-length records, the exact physical block 
reference must be given in the Record Identification field. 
The data in the new records is written in the exact location 
specified, destroying whatever was previously recorded at that 
location. 

For keyed, fixed-record additions, only the track information 
is used as a starting location for the search of a dummy key 
and record. When a dummy key and record is found, the new key 
and record replaces it, the exact location at whic;h the new 
record is located is returned to the user in the block reference 
subfield of the Record Identification field. 

For example, suppose a user wishes to add a keyed, fixed-length 
record to his DAM data set. He determines (through some 
algorithm) that the search is to start at relative track 3. 
His Record Identification field might look like the following: 

P_3__0 AL?HA 
T T R KEY" 

When control is returned to the user, his Record Identification 
field might reflect the fact that the record was added on 
relative track 4, record 6. 

4 6 ALPHA 

tIHr key" 

When adding records of undefined length, the length of the 
physical record must be placed in the TCA at TCAFCURL in a two- 
byte binary format. When an undefined record is retrieved, 
it is the user's responsibility to determine its length. 
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6. When adding variable length records to a BDAM file, it is the 

responsibility of the application programmer to insert the Block 
Length. 

JIOJESTING CAT A LANGUAGE/ I SERVICES UNDER CICS^OS 

The application programmer can reguest Data Language/I (DL/I) 
services under CICS/OS through CALL'S written according to DL/I 
specifications or by issuing a DFHFC macro instruction. In response 
to such requests, control is passed to a CICS-DL/I interface routine 
that acts as an interface between the CICS application program and 
the DL/I request handler in a DL/I task (which is an OS subtask of 
CICS) . This routine performs validity checks on the CALL list, sets 
up DL/I to handle this particular request, and passes control and the 
CALL list to DL/I. When the interface regains control, it returns 
control to the calling program unless a DL/I pseudo-abend has occurred, 
in which case the CICS transaction (task) is abended. 

QUASI-RFENTRANT CONSIDERATIONS WITH REGARD TO DL/I CALL'S 

Under IMS, programs are not required to be reentrant since only 
one transaction can use a particular program at any one time. In CICS, 
if several transactions are being serviced which require the use of 
cne application program, one copy of the program is executed in a 
reentrant manner by several CICS subtasks. Therefore, DL/I areas that 
will be modified (such as PCB pointers, I/O work areas, and Segment 
Search Arguments) may not be placed in either static storage or working 
storage. Storage for PCB pointers. Segment Search Arguments, and work 
areas must be obtained from CICS dynamic storage by each transaction 
using the program. (See the section "Quasi-Reentrance".) 

The four steps to requesting DL/I data base services are as follows: 

1. Obtain addresses of PCB's used by the application program. 

2. Acguire storage for segment search arguments (SSA's) 
if they are to be used in the CALL. 

3. Acquire I/O work areas for DL/I segments processed by the 
program. 

4. Issue the DL/I CALL. 

OBTAINING ADDRESSES OF PCB»S 

An application program that uses the CICS-DL/I interface references 
data bases by means of Proqram Communication Blocks (PCB's). In the 
Program Specification Block (PSB) for the program, there is one PCB 
for each data base. In a DL/I environment, upon entry, the application 
program receives the addresses of the PCB's of the data bases it uses. 
Since CICS handles application programs as main programs and not as 
subprograms, the PCB addresses cannot be obtained via entry conventions 
but must be obtained by the application program before it makes any 
DL/T CALL'S. 

To successfully process DL/I CALL'S within CICS transactions, the 
PSB for the transaction must be scheduled and the PCB addresses must 
be obtained before any DL/I CALL'S are made. If they are not obtained, 
any DL/I CALL'S made return an INVREQ (invalid request) indicator. 
H'he scheduling process gives the transaction exclusive control of the 
PSB. This prevents other transactions from updating segment types 
that this transaction is updating. 
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A transaction may schedule only one PSB at a time. An attempt to 
schedule a second PSB vhile one is still scheduled causes the INVREQ 
indicator to be returned. 

To schedule the desired PSB and obtain PCB addresses, the application 
programmer uses a special form of the DFHFC macro instruction: 

DFHPC TYPE=(DL/I,PCB) , * 

PSB=psbname, symbolic address, YES, * 

NORESP=symbolic address, * 
INVREQ=symbolic address 

A discussion follows concerning the operands that can be included 
in this macro instruction. 

TYPE: TYPE=(DL/I,PCB) indicates a reguest for PCB addresses. 

PSB: This operand is used to specify the name of the PSB to be used. 
The name can be the actual name enclosed in guotes, or the name of 
an eight-byte field containing the name of the PSB, padded to the right 
with blanks. If the application programmer wishes to enter the PSB 
name in the TCADLPSB field befor e the CALL, he specifies PSB=YES. 
If this operand is omitted, the name of the program associated with 
the transaction in the PCT is used as the PSB name. 

N0R5SP: This operand is used to specify the label to be branched to 
if the PSB was located and the PCB addresses were returned. If the 
PSB could not be scheduled, or if this operand is omitted, processing 
continues with the next seguential instruction. 

INVREQ: This operand is used to specify the entry label of a user- 
written routine to be given control under any of the following 
conditions: 

1. When an attempt is made to schedule a PSB while the transaction 
is still using a previously scheduled PSB. 

2. The PSB name specified is not in the PDIR (PSB Directory) list. 

3. The PSB or one of its associated DMB's (Data Management 
Blocks) does not exist in the Application Control Block (ACB) 
Library. 

U. One of the DMB's associated with the PSB is not in the DDTR 
(DMB Directory) list. 

If the PSB has been located, the TCADLPCB field contains the address 
of a list of PCB addresses which is in the sequence in which the PCB 
addresses were specified during the PSBGEN of this PSB. If the PSB 
cannot be found, TCADLPCB contains zero. If the PSB pool or DMB pool 
is too small to hold the requested blocks even when no other PSB's 
or DMB's are in their pools, the transaction is terminated with the 
DLPA abend code; DL/I pseudo- abend code 992 or 993 is placed in the 
transaction's TCA at TCADLECB and the pseudo-abend message is sent 
to destination CSMT. 

BUILDING SEGMENT SEARCH ARGUMENTS (SSA's) 

Segment Search Arguments (SSA's) can be used in a DL/I CALL to 
identify a specific segment, or, if qualified, to identify the range 
of values within which a segment exists. If used, SSA's are built 
by the application programmer before a DL/I CALL is issued. See the 
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JUS/360 App l ication Programming Re ference Manual for information 
concerning how to build an SSA. 

In a DL/I application program, SSA's are built in fixed storage 
within the program. In a CICS application program, SSA's must be built 
in dynamic storage to maintain the quasi-reentrance of the program. 

The storage acquired to build the SSA's is addressed as follows: 

1. "For Assembler language programs, the address should be placed 
in the register that establishes addressability for the SSA 
dynamic storage. 

2. For ANS COBOL programs, the address is moved to the BLL pointer 
for this storage. The BLL pointer is defined under the COPY 
DEHBLLDS statement in the Linkage Section and must be in the 
same relative position in the BLL list as the 01 statement for 
the SSA dynamic storage is among the 01 statements in the Linkage 
Section. 

3. For PL/I, the address is stored in the variable upon which the 
SSA dynamic storage is based. 

After the storage has been acquired, the Segment Search Arguments 
are built according to the DL/I specifications found in the IMS/360 
Ap plicatio n Programming Refer ence Manual. 

In a DL/I CALL statement, the names of the SSA's to be used, if 
any, are specified in the parameter list. In a DFHFC TYPE=DL/I macro 
instruction, the application programmer can specify the number and 
names of the SSA's in different ways: 

1. SSAS=NO indicates that there are no SSA's in this CALL. 

2. SSAS= (ssacount,ssa1 ,ssa2, . . . ) , where "ssacount" is optional, 
represents either the fixed-point number of SSA's in the CALL 

or the symbolic address of the fullword that contains the number 
of SSA's. Specifying a field to contain the number of SSA's 
provides the application programmer with flexibility in writing 
one DFHFC statement to be used in many different CALL'S. "ssal", 
"ssa2", etc., are the symbolic names of the SSA's. 

3. SSALIST=YES indicates that the application programmer has built 
a list of fullwords, optionally containing the number of SSA's 
(which may be zero) in the first word, and the addresses of 

the SSA's in the following words, and that he has stored the 
address of this list at TCADLSSA. 

4. SSALIST=listname indicates that "listname" is the address of 
an SSA list built by the application programmer as indicated 
in item 3. 

In Assembler language programs, "ssalist", "ssacount", "ssal", 
"ssa2", etc., can be contained in registers by enclosing the 
specification in parentheses. 

ACQUIRING AN I/O WORK AREA 

A request for services in a DL/I transaction under IMS always 
includes the address of a work area, either where a current segment 
is contained, or where DL/I is to place the segment in a retrieval 
CALL. In a CICS application program, this area must be specified in 
a CALL or CALLDLI, but may be provided by the interface, if the 
programmer desires, for a retrieval type DFHFC macro request. 
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If the application programmer knows the address of the work area 
to be used in the DFHFC macro instruction, including the case where 
he acquires storage for a retrieval type (Gxxx) request, he specifies 
either the name of the pointer to that storage in the WRKAREA=name 
operand, or places the address of the storage in TCADLIO and specifies 
?3KAREA=YES. 

If the application programmer wishes to allow the interface to 
obtain the work area for a retrieval-type request, he does not include 
the WRKAREA operand in the DFHFC macro request; if the request was 
se -?v iced successfully, the address of an acquired I/O work area is 
p ound at TCADLIO. The address at TCADLIO is the address of the Storage 
Accounting Area (SAA) preceding the retrieved data. The length of 
th : data is eight bytos less than the value found in the second halfword 
of the SAA. The area becomes the responsibility of the programmer 
and is not freed until he frees it or until the transaction terminates. 

No te: The address of the I/O area is specified as the address of the 
Storage Accounting Area preceding the data for a DFHFC request, 
or as the address of the first byte of the data area for a CALL 
or CALLDLI. 

ISSUING THE DL/I CALL 

A CICS application program can request DL/I services in either of 
two ways: CALL'S written according to DL/I specifications or DFHFC 
macro requests using unique DL/I operands. 

I2£ Assembler, l angu age: 

CALLDLI ASMTDLI, (parmcount, function, pcb, workarea, segment 

search arguments,...) or 
CALLDLI CBLTDLI, (parmcount , function, pcb, workarea , segment 

search arguments,...) 

In this macro instruction, which alters the contents of register 
1, "parmcount" is an optional parameter. The operation code is CALLDLI 
rather than CALL since the expansion of the CALL to the interface is 
not the same as the ordinary expansion of a CALL. If no parameters 
are specified, it is assumed that register 1 contains the address of 
the parameter list. ASMTDLI and CBLTDLI are functionally equivalent 
specifications. 

An alternate form of this specification is: 

CALLDLI ASMTDLI, MF= (E, (register) or address) or 
CALLDLI CBLTDLI, MF=(E, (register) or address) 

which is written in the same format as the E-TYPE OS CALL macro 
instruction; that is, "address" is the address of the parameter list 
or "register" contains the address of the parameter list. 

for ANS COBOL: 

CALL 'CBLTDLI* USING parmcount , function, pcb, workarea, 

segment search arguments,... 



^or PL/T: 



CALL PLITDLI (parmcount , function , pcb, workarea, 
segment search arguments,...); 
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Note: In a CALLDLI or CALL statement, the "workarea" parameter must 
point to the first byte of the data area. 

The following macro instruction is used to specify the desired DI/I 
functions to be performed, regardless of the programming language used: 

DFHFC TY?E=(DL/I, function) , * 

PCB=symbolic address, (register) , * 

WRKARFA=symbolic address, YES, (register) , * 

SSAS=NO, (ssacount,ssal,ssa2, . . .) , * 

SSALIST=YES, NO, symbolic address, (register) , * 

NORESP=symbolic address, * 

NOTOPEN=symbclic address, * 
INVREQ=symbolic address 

TYPE: This operand is used to specify the two- to four-byte name of 
the function to be performed. If it is not specified, the function 
must have been specified in the TCADLFUN field before the DFHFC macro 
instruction is issued. 

^CB: The PCB=symbolic address operand is used to specify the name 
of the field that contains the address of the PCB. 

WRKAREA: WRKAREA=YES indicates that the application programmer has 
placed the address of the work area to be used at TCADLIO. 

WRKAREA=symbclic address specifies the address of the field that 
contains a pointer to the I/O work area. 

If the WRKAREA operand is not specified and this is a Gxxx request, 
the CICS-DL/I Interface acquires storage for the work area and stores 
the address at TCADLIO. The user must save this address upon return. 
In any other type of request, the user must provide the work area. 

Note: The work area whose address is specified in a DFHFC macro 

instruction or whose address was previously placed at TCADLIO 
includes, the CICS Storage Accounting Area prefix; the work area 
specified in a CALLDLI or CALL statement does not. 

SSAS: SSAS=NO indicates that there are no SSA's used in this request. 
SSAS=NO is the default specification. 

SSAS= (ssacount, ssal, ssa2, ...) is used to specify the names of 
Segment Search Arguments in this request (thereby creating an SSA 
list), "ssacount" is used, optionally, to specify the number of SSA's 
to be used in this request; this parameter represents the address of 
a fullword containinq the count, or, in the case of Assembler languaqe, 
may be expressed as a numeric value. If the ssacount parameter is 
omitted, the ssal specification represents the first element of the 
SSA list. For a further description of the SSA list, see the following 
discussion under SSALIST. 

SSALIST: SSALIST= symbolic address is used to specify the name of 
a field that contains the address of an SSA list. The first element 
of an SSA list may, optionally specify either the number of SSA's to 
be used in this request or the address of a full word containing this 
value; the remaining elements represent addresses of SSA's. If the 
first element of an SSA list does not represent "ssacount", all elements 
of the SSA list are assumed to be addresses of SSA's; the high-order 
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bit of the last element of the list must be set on to indicate the 
end of a variable-length list. 

SSALTST=YES indicates that the user has previously placed the address 
of the SSA list at TCADLSSA. 

SSALTST=NO indicates that no SSA list is used in this request. 
The default is SSALIST=NO. 

If either WRKAREA=YES or SSALIST=YES is specified the address of 
the I/O work area or SSA list must be placed in the TCA prior to issuing 
the DFHFC macro instruction. The TCA fields containing these addresses 
are altered during the service of the request. 

Note: SSAS and SSALIST are mutually exclusive operands. 

NORESP: NOEESP=name is used to specify the label to which control 
is to be passed after this transaction has regained control. The CICS- 
DL/I Interface must have been able to pass control to DL/I and a DL/I 
pseudo-abend of the transaction must not have occurred. The user must 
check the return code in the PCB to see if DL/I was able to properly 
service the request. If this operand is omitted, control is passed 
to the next sequential instruction. 

NOTOPEN: NOTOPEN=symbolic address is used to specify the label to 
which control is to be passed if this data base is logically (not 
necessarily physically) closed. The PCB will not contain an AT status 
code. 

TNVREQ: INVREC_=symbolic address is used to specify the label of a 
user-written routine to which control is to be returned if the 
transaction attempts to access DL/I without first scheduling a PSB 
and obtaining PCB addresses. 

Note: In Assembler language application programs certain operands 

may be specified as registers and enclosed in parentheses; for 
example: 

1: PCB= (register) where "reg" contains the address of the PCB to 
be used in this reguest. 

2: WRKAREA= (register) where "reg" contains the address of the work 
area to be used in this request. 

3: SSAS= ( (register 1), (register 2), (register 3),...) where 

"register 1" contains the optional count of SSA's, and "register 
2", "register 3", etc., point to SSA's to be used. 

4: SSALIST= (register) where "register" points to a previously 
constructed SSA list (described above under SSALIST=symbolic 
address) . 

RELEASING A PSB IN THE CICS APPLICATION PROGRAM 

To reduce pool and intent contention, the CICS application program 
may release the PSB. Eefore making any other DL/I CALL»s, the program 
must again issue a scheduling CALL. 
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Tt is recommended that conversational programs release the PSB 
before writing to a terminal so that other transactions can use the 
PSB while the conversational program is waiting for an operator 
response. 

A CICS application program can release a PSB for use by other 
transactions by issuing a 

DFHFC TYPE={Dt/I,T) 

request. The PSB is released for use by other transactions, or if 
not required, its pool space and associated DHB pool space may be 
released. No other DL/I CALL'S may be made in this transaction until 
another scheduling (PCB) CALL is made. 

CHECKING THE RESPONSE TO A REQUEST FOR DL/I SERVICES (CHECK) 

To test whether or not the CICS-DL/I Interface successfully processed 
the DL/I request, the 

DFHFC TYPE=CHECK, * 

NORESP=symbolic address, * 

INVREQ=symbolic address, * 
NOTOPEN=symbclic address 

macro instruction can be issued. 

NOBESP: NORESP is used to specify the label of the user-written routine 
to which control is to be passed upon normal execution of the reguest. 

INVREQ: INVREQ is used to specify the label of the user-written routine 
to which control is to be passed in the event the transaction has not 
scheduled a PSB and obtained PCB addresses. 

NOTOPEN: NOTOPEN specifies the label of a user-written routine to 
which control is to be passed in the event the requested data base 
named in the PCB used in the reguest was logically (not necessarily 
phvsically) closed. The PCB will not contain an AI status code. 

The application programmer may use the DFHFC TYPE=CHECK macro 
instruction following a CALLDLI, CALL, or DFHFC TYPE= (DL/I) . This 
macro instruction does not check for DL/I return codes in the PCB. 
In the event DL/I issues a pseudo-abend during processing of the 
request, control is not returned to the transaction. The transaction 
is terminated with CICS abend code DLPA. 

DL/I REQUESTS WRITTEN IN ASSEMBLER LANGUAGE 

The application programmer must first get the PCB addresses. (There 
are several examples below.) When CICS returns from servicing the 
DFHFC TYPE= (DL/I, PCB) request, if the programmer loads register 1 from 
TCADLPCB, his program is in the same state as after an 

ENTRY DLITCBL 

statement wVen executing an IMS DL/I application program. 

The examples that fellow show the options available to the 
application programmer in a few of the acceptable combinations. Note 
that the application program must be kept quasi-reentrant; that is, 
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addresses, etc., should not be stored in static storage. Note also 
that if a DFHFC macro insturction is used the PCB and WRKAREA operands 
are used to specify the address of a pointer to the field rather than 
the field itself. 

For a complete discussion concerning the checking of these responses, 
see the section "Test Response to a Request for File Services". 

The following is an example of the coding required to request DL/I 
services in an Assembler language application program. 



COPY DFHTCADS 

FSBNAME DC CL8 • PSBNAME1 • 

PCBPTRS DSECT 

* 

FCB1PTR DS F 

FCB2PTR DS F 



COPY TCA DEFINITION - INCLUDES 

DL/I FIELDS 

NAME OF PSB TO BE USED 

PCB POINTERS RETURNED BY 

INTERFACE 

STORAGE FOR PCB POINTERS 



WORKAPTR DS F 
*>CB1 DSECT 



STORAGE FOR PRINTER IN I/O WORK 

AREA 

PCB DSECT 



PCB2 



DSECT 



PCB DSECT 



WRKAREA 


DSECT 




DS 2F 


W0RKA1 


DS CL40 


SSAREA 


DSECT 




DS 2F 


SSA1 


DS cmo 


SSA2 


DS CL20 



DL/I WORK AREA DSECT 
STORAGE PREFIX 
WORK AREA 
SSA DSECT 
STORAGE PREFIX 
SSA1 LAYOUT 
SSA2 LAYOUT 



DFHFC TYPE= (DL/I, PCB) 
DFHFC TYPE= (DL/I, PCB) , 

PSB=«PSB1U» 
DFHFC TYPE= (DL/I, PCB) , 

PSB=psbname 
MVC TCADLPSB,=CL8»PSBA» 
DFHFC TYPE= (DL/I, PCB) , 

PSB=YES 
L R1,TCADLPCB 
USING PCBPTRS, R1 



USE PSB FOR THIS PROGRAM 

GET PCB'S IN «PSB14« i 

GET PCB'S IN SPECIFIED PSB » 

PUT PSB NAME IN TCA 

GET PCB»S OF PSB NAMED IN TCA ' 

GET ADDRESS OF PCB ADDR LIST 
PEG 1 IS BASE OF PCB POINTEFS ~ 
USER MUST PROVIDE ADDRESSABILITY 
TO PCB'S WHEN USING THEM 



* ACQUIRE STORAGE FOR WORKAREA 

DFHSC TYPE=GETMAIN,... 
L R2,TCASCSA 
USING WRKAREA, R2 

* ACQUIRE STORAGE FOR SSA'S 

DFHSC TYPE=GETMAIN,... 

L R3,TCASCSA 

USING SSAREA, R3 
* 

CALLDLI CBLTDLI, (funct ion, PCB 1 , WRKAREA, SSA1 ,SSA2) 
* 



GET STORAGE FOR WORKAREA 
REG 2 IS BASE FOR WORKAREA 
TELL ASSEMBLER 

GET STORAGE FOR SSA'S 
REG 3 IS BASE FOR SSA'S 
INDICATE TO ASSEMBLER 
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CALL DL/T VIA DFHFC MACRO — VARIOUS EXAMPLES 
EXAMPLE 1 



DFHFC TYPE= (DL/I, function) , 
PCB=PCB1PTR, 
WRKAREA=WORK APTR , 
SSAS=(2,SSA1,SSA2) , 
N0RESP=GOOD1 



EXAMPLE 2 



MVC TCADLPCB,PCB1PTR 
LA RO,WRKAREA 
ST R0,TCADLIO 
DFHFC TYPE=(DL/I,DLET) , 

WRKARIA=YES, 

SSAS=NO 



EXAMPLE 3 



MVC TCADLFUU f =CL4«GTP 
DFHSC TYPE=GETMAIN,... 



L 


RU,TCASCSA 


LA 


R4,8(RU) 


LA 


R0,1 


ST 


RO,0(RU) 


LA 


R0,SSA1 


ST 


R0,4 (R4) 


ST 


R4,TCADLSSA 


01 


U(R4) ,X«80» 


DFHFC 


TYPE=DL/I, 




PCB=PCB1PTR, 




SSALIST=YES 


L 


R3,TCADLI0 



PCB IS POINTED TO 

WORKAREA IS POINTED TO 

SSA COUNT AND SSAS SPECIFIED 

NORMAL RESPONSE BRANCH 



PRELOAD PCB POINTER 

PICK UP WORK AREA ADDRESS 

STORE IN TCA 

FUNCTION SPECIFIED 

WORKAREA ADDRESS PRELOADED 

NO SSAS 



PRELOAD FUNCTION 

GET STORAGE FOR SSA LIST 

PICK UP STORAGE ADDRESS 

BYPASS PREFIX 

GET COUNT OF SSAS 

STORE IN SSA LIST 

GET ADDRESS OF «SSA1« 

STORE IN SSA LIST 

STORE LIST ADDRESS IN TCA 

SET ON THE END-OF-LIST BT 1 " 

DL/I CALL, FUNCTION PRELOADED * 

POINTER TO PCB TO BE USED * 

INTERFACE WILL PROVIDE WORK AREA* 

PROBLEM PROGRAM PROVIDES SSA LIST 

PICK UP ADDRESS OF SUPPLIED 

WORKAREA 



CL/I REQUESTS WRITTEN IN ANS COBOL 

Upon program entry the ANS COBOL programmer should obtain PCB 
addresses by issuing a DFHFC TYPE= (DL/I, PCB) reguest. After CICS 
returns control, the programmer moves the TCADLPCB field to the BLL 
pointer which is the base for the layout of the PCB pointers in the 
Linkage Section. He then moves the addresses of the PCB's to their 
BLL pointers to provide the base addresses for the PCB's. When this 
is done, the program is in the same state that it would be in after 
execution of the ENTRY »DLITCBL I USING PCB1,PCB2 statement if the 
program were written for DL/I. 

For an explanation of how BLL pointers to 01 statements in the 
Linkage Section are defined, see the discussion of ANS COBOL application 
programming in the section "Storage Definition". 

Various examples are provided below concerning how to write DL/I 
reguests; only some combinations of operands are shown, but other 
combinations are acceptable. Note that in a DFHFC reguest the BLL 
pointers to the PCB and work area are used rather than the actual field 
names themselves. This is the only way the addresses can be passed 
to DL/I. 

The following is an example of the coding reguired to reguest DL/I 
services in an ANS COBOL application program: 
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WORKING-STORAGE SECTION. 

77 PSBNAME PICTURE X(8) VALUE »COBOLPSB». 

77 FUNCTION- 1 PICTUBE X (4) VALUE • DLET'. 

77 SSA-COUNT PICTUBE 9(8) COMPUTATIONAL VALUE +2. 

LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS 

02 ... POINTEBS TO OTHER CICS ABEAS 

* NEEDED 

02 B-PCB-PTEs PICTUBE 9(8) COMPUTATIONAL. 

02 B-PCB1 PICTUBE 9(8) COMPUTATIONAL. 

02 B-PCB2 PICTUBE 9(8) COMPUTATIONAL. 

02 B-WOBKAREA PICTUBE 9(8) COMPUTATIONAL. 

02 B-SSAS PICTURE 9(8) COMPUTATIONAL. 
01 DFHCDASD COPY DFHCSADS. 
01 DFHTCASD COPY DFHTCADS. 

NOTE TWO DEFINITIONS. 

NOTE OTHEB ABEA DEFINITIONS. 

01 PCB-PTRS. 

02 PCB1-PTR PICTUBE 9(8) COMPUTATIONAL. 

02 PCB2-PTB PICTUBE 9(8) COMPUTATIONAL. 
01 PCB1-. 



01 PCB2. 



01 HOBKABEA. 

02 FILLER PICTURE X(8). 
02 WORKA1 PICTUBE X {HO) 



STORAGE PBEFIX, 



01 SSABEA. 

02 FILLEB PICTUBE X(8) 
02 SSA1 PICTUBE X(40) . 
02 SSA2 PICTURE X(60) . 



PROCEDURE DIVISION. 

* GET PCB ADDRESSES 

DFHFC TYPE=(DL/I,PCB) GET PSB FOE THIS PROGRAM 

* SAVE PCB ADDRESSES IN 3LL TABLE SO PCB'S CAN BE ADDRESSED 

MOVE TCADLPCB to B-PCB-PTRS 
MOVE PCB1-PTR to B-PCB1 
MOVE PCB2-PTR to E-PCB2 

* OPTIONALLY ACQUIRE STORAGE FOB WORK ABEA 

DFHSC TYPE=GETMAIN,.. . 
MOVE TCASCSA to B-WORKAREA. 

* OPTIONALLY, ACQUIRE STORAGE FOR SEGMENT SEARCH ARGUMENTS 

DFHSC TYPE=GETMAIN, . . . 
MOVE TCASCSA to B-SSAS. 

* CALL DL/I VIA CALL 

CALL 'CBLTDLI* USING FUNCTION- 1 , PCB 1 , WOBKAREA, SSA1, SSA2. 

* EXAMPLE 1 OF DFHFC MACRO INSTRUCTION 

DFHFC TYPE=(DL/I,GHU) , FUNCTION 

PCB=B-PCB1, PCB POINTER 

WRKAREA=B-WORKAREA, WOBKABEA POINTER 
SSAS= (SSA-COUNT, SSA1,SSA2) SSA COUNT AND NAMES 

* EXAMPLE 2 OF DFHFC MACRO INSTRUCTION 

MOVE «GNP» to TCADLFUN NOTE PRELOAD FUNCTION. 

MOVE B-PCB1 to TCADLPCB NOTE PRELOAD PCB ADDRESS. 
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DFHFC TYPE=DL/I, 



SSAS=NO 
MOVE TCADLIO to B-WORKAREA. 



FUNCTION PRELOADED * 

PCB ADDRESS PRELOADED * 

WORKAREA TO BE ACQUIRED * 

NO SSA»S 
NOTE SAVE ACQUIRED WORK AREA ADDR. 



DL/I REQUESTS WRITTEN IN PL/I 

Upon entry to his program, the PL/I application programmer should 
get PCB addresses via a DFHFC TYPE= (DL/I, PCB) statement. When CICS 
returns, the BASE of a structure of PCB pointers is in TCADLPCB. The 
PL/I programmer must move the BASE value from TCADLPCB to the BASE 
of his declared structure of PCB pointers. He then loads the BASE»s 
of all the PCB's from this structure. The program is now in the same 
state that the DL/I application program would be following execution 
of the 

DLITPLI: PROCEDURE (pcfcnamel, . ..) OPTIONS (MAIN); 

statement, if the program were an IMS DL/I application program. 

The PL/I programmer may then make DL/I reguests, either via CALL*s 
or via DL/I DFHFC macro instructions. Note that in a DFHFC reguest 
the PCB and WRKAREA operands specify the address of a pointer to the 
field rather than the field itself. 

The following is an example of the coding reguired to reguest DL/I 
services in a PL/I application program: 



^INCLUDE DFHCSADS; 
^INCLUDE DFHTCADS; 



/* CSA DEFINITION */ 
/* TCA DEFINITION - INCLUDES */ 
/* DL/I FIELDS */ 
DECLARE, 1 PCB POINTERS BASED (B_PCB_PTRS) , 

2 PCB1_PTR POINTER, 

2 PCB2~PTB POINTER; 



/* 
/* 



/* 



DECLARE 1 PCB1 BASED (BPCB1), 

2 ... 

o 

4* • • • | 

DECLARE 1 PCB2 BASED (BPCB2) , 

2 ... 
o 

Cm • • • f 

DECLARE 1 DLI_IOAREA BASED (BDLIIO) , 
2 STORAGE_PREFIX CHAR (8) , 
2 IOKEY CHAR (6) , 

4b • • • | 

DECLARE 1 DLT_SSADS BASED (BSSADS) , 
2 STGRAGE^PREFIX CHAR (8) , 
2 SSA1, 

3 SSAlKi."" CHAR (6) , 
3 ... 
2 SSA2, 
j ... 
3 . . . • 
OBTAIN PCB POINTERS */ 
DFHFC TYPE= (DL/I, PCB) 
SAVE POINTERS IN PCB BASES */ 
B_PCB_PTRS*=TCADLPCB ; 
BPCB1=PCB1_PTR; 
BPCB2=PCB2~PTR; 

ACQUIRE STORAGE FOR DL/I I/O AREA */ 
DFHSC TYPE=GETMAIN,CLASS=USER, . . . 
BDLIIO=TCASCSA; 



/* PCB DEFINITIONS */ 



/* DL/I */ 

/* 1-0 AREA */ 

/* DEFINITION */ 

/* DL/I */ 

/* SSA */ 

/* DEFINITIONS */ 
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/* OPTIONALLY ACQUIRE STOHAGB IN WHICH TO BUILD SSA»S */ 

DFHSC TYPE=GETMAIN,CLASS=USER,... 

BSSADS=TCASCSA; 
/* OPTIONALLY BUILD SEGMENT SEARCH ARGUMENTS */ 

SSA1KEY=TERMKEY; 



/* CALL DL/I */ 

CALL PLITDLI (PAFM_CT, DLI_FUNCTION, PCB1 , IOKEY,SSA1 , 
SSA2) ; 
/* EXAMPLE 1 OF DFHFC MACRO INSTRUCTION ■ */ 

DFHFC TYPE=(DL/I,ISRT) , * 

PCB=BPCB1, PCB POINTER * 

WRKAR1A=BDLII0, WORK AREA POINTER * 

SSAS=(2,SSA1,SSA2) SSA COUNT AND NAMES 

/* EXAMPLE 2 OF DFHFC MACHO INSTRUCTION */ 

TCADLPCB=BPCB1; PRELOAD PCB POINTER 

DFHFC TYPE=(DL/I,GU) , PCB PRELOADED * 

WORKAREA TO BE ACQUIRED * 

SSAS=(SSA_C0UNT,SSA1,SSA2) SSA COUNT NAMES 
BDLTIO=TCADLIO; /* SAVE ACQUIRED WORK AREA ADDR */ 

/* EXAMPLE 3 OF DFHFC MACRO INSTRUCTION */ 

TCADL7UN=»GN' ; /* PRELOAD FUNCTION */ 

TCADLIO=BDLIIO; ' /* PRELOAD WORKAREA ADDRESS */ 

DFHFC TYPE=DL/I, FUNCTION PRELOADED * 

PCB=BPCB1, PCB POINTER * 

WRKAREA=YES, WORK AREA ADDRESS PRELOADED * 

SSAS=NO NO SSA'S 

1ASTC MAPPING SUPPORT FOR THE 3270 

CICS provides Basic Mapping Support (BMS) for use with the IBM 3270 
Information Display System. By use of BMS, the CICS application 
programmer has access to input and output 3270 data streams without 
the need to include any 3270 device-dependent code in the CICS 
application program. 

Application programs that utilize BMS under CICS remain independent 
of the 3270 data stream format. They also remain compatible with 
future additions of new fields to the existing input and output map 
formats. 

Two types of maps are assembled offline through use of CICS macro 
instructions: (1) a physical map which is used by CICS to convert 
3270 native mode data into the format desired by the application 
programmer, and (2) a symbolic description map which is used by the 
application programmer to symbolically reference the data in the 3270 
buffer. The CICS DFHMDI macro instruction is used to build both types 
of maps; DFHMDI TYPE=MAP indicates a physical map while DFHMDI 
TYPE=DSECT indicates a symbolic description map. 

The user defines and names fields and groups of fields that may 
be written to and received from the 3270. The assembled physical map 
contains all the 3270 device-dependent control characters necessary 
for the 3270 data stream. 

The symbolic description map can be copied into each application 
program that uses the associated physical map. Data is passed to and 
from the application program under the field names in the symbolic 
description map. Since the application program is written to manipulate 
the data by referencing each field by name, altering the map format 
by adding new fields or rearranging old fields does not necessarily 
alter the program logic. 
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If the map format is altered, it is necessary to make the appropriate 
changes in the macro instructions that describe the map and then 
reassemble both the physical map and symbolic description map. The 
new symbolic description map must then be copied into the application 
program and the program reassembled. 

An application program has access to the input and output data 
fields using the names supplied to the fields when the maps were 
generated. The application logic should be dependent upon the named 
fields and their contents but should be independent of the relative 
positions of the data fields within the screen format. If it becomes 
necessary to reorganize or add to a map format, the existing application 
program must be reassembled to gain access to the new positions of 
these data fields. Reprogramming is not necessary to account for new 
fields or for the changed screen format of those fields. 

Basic Mapping Support (BMS) is available to application programmers 
coding in PL/T, ANS COBOL, or Assembler language. Input maps describe 
the fields which are potentially receivable from a 3270 screen; output 
maps specify the format of data to be sent to a 3270 screen or printer. 

By using BMS to construct and interpret the 3270 data streams, 
application programmers can insulate application programs from the 
device-dependent considerations required to handle 3270 data streams. 
If necessary, the application program has the facility to temporarily 
modify the attributes of an output map or of any named field in an 
output map. BMS supplies a collection of named attribute combinations 
so that the application program remains essentially independent of 
the 3270 data stream format. 

The ability to progressively add to map definitions without 
obsoleting existing application programs permits the design and 
implementation of systems in a modular fashion with a progressive 
expansion of the 3270 formats. Design and programming of the first, 
stages of applications can begin before later stages have even been 
designed. This early implementation is protected from updates in the 
screen formats. 

MAP DEFINITION 
2.D2fi£ Mapping 

Input maps are defined using the DFHMDI and DFHMDF macro instructions 
during offline map generation. 

Each field to be read must be defined as to maximum data length 
and starting position. This operation produces a map and a symbolic 
storage definition of the TIOA data supplied by BMS. 

The physical map is used by BMS to construct a TIOA as defined by 
the symbolic storage definition to be returned to the user transaction. 

The tioa symbolic storage definition contains the length of the 
input data followed by the data read. Space is reserved for the maximum 
length defined for each field (not to exceed 256 bytes) . 

Pen-detectable fields have one reserved byte that contains a 
hexadecimal 'FF' if the field is selected or a hexadecimal '00* if 
the field is not selected. The length field always contains a half word 
binary one. 

The length specified may differ from the actual number of characters 
in the field. If more data is keyed than specified, the data is 
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truncated to the number of characters requested in the map; the length 
is returned as the truncated length. If less data is keyed than 
specified, the remaining character positions are filled with blanks 
or zeros and the length of the keyed data is returned in the length 
field. The maximum length allowed for any one field is 256 characters. 

Any keyed fields not defined by the map are discarded. Any fields 
defined but not keyed have their length field set to zeros and the 
data field set to nulls (X'OO 1 ). 

The program can access the length or data of any field by symbolic 
labels. The length field is a halfword binary field and is addressed 
by the label "fieldname. L" or "groupname.!". The data portion of each 
field (or group of fields) is contiguous with the length field. A 
group of fields, or a single field not within any group of fields, 
has the data portion addressed by the name "groupname. I" or 
"fieldname. I". For fields contained within a group, there are no 
intervening length fields (only "groupname.!" exists) and each field 
has the name "fieldname. I". 

Note that the "." is a concatenation symbol and is not used when 
referencing either the data or the data length. For example, in the 
case of field name XYZ, the data is referenced as XYZI; the data length 
is referencad as XYZL. 

PHiEUt Happing 

Output maps, like input maps, are created offline during map 
generation using the DFHMDI and DFHMDF macro instructions. Each field 
to be displayed must be defined as to starting location, length, field 
characteristics, and default data (if desired). 

When defining fields, the user may name any field he desires to 
override at execution time. Any named fields are produced in a symbolic 
storage definition of the TIOA to allow symbolic reference to each 
field. The user may temporarily override the field characteristics, 
the data, or both field characteristics and data, by inserting the 
desired changes into the TIOA under the field names in the symbolic 
storage definition map which he has in his program. 

The fields are assigned names as specified in the DFHMDF macro 
instruction. The characteristic or attribute byte is named 
"fieldname. A" or "groupname. A". For a field contained within a group, 
the data area is given the name "fieldname. 0", and there is no separate 
attribute byte for the field. (Only groupnames can have an attribute 
byte.) For a groupname, or a field not contained within a group, the 
data area is given the name "groupname. O" or "fieldname. 0". A field 
not contained within a group is treated as a group containing just 
a single field entry. 

Note that the "." is a concatenation symbol and is not used when 
referencing either the data or the data attributes. For example, in 
the case of field name XYZ, the data is referenced as XYZO; the 
attribute byte is referenced as XYZA. 

Pen-detectable fields should be "auto skip" to prevent data from 
being keyed into them. 

Note ; Due to the nature of the pen-detectable fields, they should 
normally not be modified. However, if the data field is 
modified, the first character must be a "?" or blank character; 
otherwise, the field is no longer pen detectable. 
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Output field data, whether initial map data or data supplied by 
the program, must not begin with a null character (X*00'). Blank 
characters (X'40') should be used to position displayable data 
down a field. 

OFFLINE MAP BUILDING 

The following macro instruction is the initial and final macro 
instruction for offline map generation and is used to build the physical 
map and symbolic description map: 

mapname DFHMDI TYPE=DSECT,MAP,FINAL, * 

TERM=3270, * 

LANG=ASM, COBOL, PL1, * 

BASE=name, * 

MODE=IN,OUT, * 
CTRL= (PRINT, L40,L64,L80,HONEOM,FREEKB, ALARM, FRSET) 

All maps must be given a user-defined map name of from one to seven 
characters, beginning with an alpha character. If the map is to reside 
in the CICS program load library, the map name chosen must be different 
from other map names or program names in the system. 

TYPE=MAP or TYPE=DSECT may be specified if this is the initial macro 
instruction for offline map generation; TYPE=MAP indicates a physical 
map and TYPE=DSECT indicates a symbolic description map. TYPE=FINAL 
must be specified if this is the final macro instruction. 

When a symbolic storage definition is generated in response to a 
DFHMDI TYPE=DSECT, MODE=IN specification, an "I" is appended to each 
map name; when generated in response to a DFHMDI TYPE=DSECT, MODE=ODT 
specification, an "0" is appended to each map name. For example: 

MAPI DFHMDI TYPE=DSECT, * 

TERM=3270, * 

LANG=ASM, * 
M0DE=IN,. . . 

In this example, the name generated in the symbolic storage 
definition is MAP1I and must be referenced as such within the 
application program. This is true irrespective of the programming 
language used. 

DSECT: A DSECT (symbolic storage definition) map generation run creates 
the list of field names which the user copies or includes in the 
application program. If the same map definition is used by application 
programs written in different languages, a separate DSECT run is 
required for each language to put the table of field names into the 
Copy library of each language. 

MAP: A MAP generation run creates the control information block used 
by BMS to perform the mapping. This map is stored in the CICS program 
load library and is loaded as required by BMS. The Assembler language 
application programmer may generate the map in his code and pass the 
address across to BMS. 

FINAL: This parameter must always be coded as part of the last macro 
instruction of a map definition (after all the field definition macro 
instructions) . No other operands are required with DFHMDI TYPE=FINAL; 
they are ignored if coded. 
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TERM: This operand can only contain the 3270 keyword parameter. If 
this operand is omitted, it defaults to TERM=3270. 

LANG: Required only for a DFHMDI TYPE=DSECT run, this operand is 
ignored in the case of the DFHMDI TYPE=MAP and DFHMDI TYPE=FINAL 
specifications, both of which are language independent. 

BASE: The BASE=name operand is used to group symbolic storage 
definitions by specifying the group name in each applicable DFHMDI 
TYPE=DSECT specification. This operand is applicable only when the 
programming language is ANS COBOL or PL/I; it is not applicable in the 
case of a TYPE=MAP operation or if the programming language is Assembler 
language. 

The following example illustrates the use of the BASE operand: 

MAPI DFHMDI TYPE=DSECT, * 

LANG=COBOL, * 

MODE=IN, * 

BASE=DATAREA1 ... 

MAP2 DFHMDI TYPE=DSECT, * 

LANG=COBOL, * 

MODE=OUT, * 

BASE=DATAREA1 ... 

The symbolic storage definitions of this example might be referenced 
in an ANS COBOL application program as follows: 

LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS. 



02 TIOABAR PICTURE S9(8) COMPUTATIONAL. 
02 MAPBASE1 PICTURE S9 (8) COMPUTATIONAL. 



01 DFHTIOA COPY DFHTIOA. 

01 DATAREA1 PICTURE X(1920). 

01 name COPY MAP1I. 

01 name COPY MAP20. 

MAPI and MAP2 multiply redefine DATAREA1 ; only one 02 statement is 

needed to establish addressability. However, the program can only 

reference fields in one of the symbolic map areas at a time; to 

reference fields in the other symbolic map areas, the program must 
establish addressability to each of those areas. 

If BASE=DATAREA1 is deleted from this example, an additional 02 
statement is needed to establish addressability for MAP2; the 01 
DATAREA1 statement would not be needed. The program could then 
reference fields concurrently in both symbolic map areas. 

In PL/I application programs, the name specified in the BASE operand 
is used as the name of the pointer variable on which the symbolic 
storage definition is based. If this operand is omitted, the default 
name (BMSMAPBR) is used for the pointer variable. The PL/I programmer 
is responsible for establishing addressability for the based structures, 
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MODE: MODE=IN specifies an input map generation. MODE=OUT specifies 
an output map generation. This operand is not reguired for the DFHMDI 
TYPE=EINAL macro instruction. 

CTRL: This operand is used to specify various control functions for 
a particular output map which are allowable on certain of the 3270 
devices. This operand is not reguired for input maps. 
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CTRL=PRINT, CTRL=L40, CTRL=L64, CTRL=L80, and CTRL=HONEOM are options 
that relate exclusively to the printer functions. CTRL=PRINT must be 
specified if the printer is to be started; otherwise, the data is sent 
to the printer buffer but is not printed. CTRL=LU0, CTRL=L64, CTRL=L80, 
and CTRL=HONEOM are mutually exclusive options that control the line 
length on the printer. The L40, L64, and L80 parameters force a 
carriage return/line feed at the end of their specified numbers of 
characters, respectively. CTRL=HONEOM causes the printer to honor all 
new-line (NL) characters and the first end-of-message (EM) character 
that appear in displayable fields of the data stream. It is the user's 
responsibility to insert these characters into displayable fields if 
they are to be honored. If the NL character is omitted, a carriage 
return/line feed occurs at the physical end of the carriage or at the 
right margin stop, whichever is encountered first. 

When a data entry key is used by the 3270 operator, the keyboard is 
inhibited from entering further data. CTRL=FREEKB specifies that the 
keyboard should be unlocked when this map is written out. 

CTRL=ALARM is used to activate the 3270 audible alarm special 
feature. 

CTRL=FRSET (field reset) specifies that the modified data tags 
(MDT's) of all fields currently in the 3270 data buffer are to be reset 
to the "not modified" condition before any map data is written to the 
buffer. This allows the DFHMDF ATTRB specification for the reguested 
map to control the final status of any fields which are written or 
rewritten in response to an online mapping (DFHBMS) service reguest. 

The following macro instruction is used during offline map generation 
to define individual fields within a map: 

name DFHMDF * 

LENGTH=number, * 

POS=number, * 

ATTRB= (ASKIP,PROT,UNPROT,NUM,BRT,DRK,NORM,DET,IC,FSET) , * 

JUSTIFY= (LEFT, RIGHT, BLANK, ZERO) , * 

INITIAL='any user information 1 , * 
GRPNAME=user group name 

Fields must be defined in ascending order based on the value 
specified in the POS operand. 

The name field of the DFHMDF macro instruction is optional. If 
coded, the one- to seven-character name is used by the user-written 
application program as a symbolic reference to the output map field 
and is used to pass the data both for input and output map operations. 

If the name field is omitted, symbolic reference to the field by 
the application program is not possible. For an output map, omitting 
the name field is appropriate when the INITIAL operand is used to 
specify field contents. An input map field description with no field 
name causes no symbolic storage definition entry to be generated for 
the field; this prevents any access to the field by the application 
program. 

All field names and group names specified when defining fields for 
a symbolic storage definition (DFHMDI TYPE=DSECT) are suffixed by CICS 
with an "I" if MODE=IN specified and an "O" if MODE=OUT is specified. 
The entire name, including suffix, must be used within the application 
program to reference the fields, irrespective of the programming 
language used. 
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LENGTH: This operand is used to specify the length (1 to 256 bytes) 
of the individual field. Although an attribute byte is associated with 
each field, its length is not included in the LENGTH value. 

POS: This operand is used to specify up to 1920 individually 
addressable character locations (0-1919) possible in a map. The value 
specified is the location of the attribute byte that precedes each 
field. For input fields, the POS=number specification should be the 
same as that specified for the keyable or detectable field generated 
in the output map (which is the source of this input field) . 

The location of the data on the device depends on the model of the 
3270 being used. For the 480-character 3270, any POS=number 
specification that is an integral multiple of 40 results in a new line; 
any POS=number specification for the 480-character 3270 greater than 
479 produces unpredictable output. For a 1920-character 3270, a 
POS=number specification that is an integral multiple of 80 results in 
a new line. 

For printers, new lines are determined by the CTRL specification of 
the DFHMDI macro instruction; the POS specification controls only those 
character positions that are. in the buffer. 

All DFHMDF macro instructions must be coded in ascending order based 
on the value specified in the POS operand. Otherwise, fields may be 
omitted during input or output mapping operations. 

ATTRB: This operand is used to specify the device-dependent 
characteristics and attributes applicable to individual fields. 
Applicable keyword parameters are ASKIP, PROT, UNPROT, NUM, BRT, DET, 
DRK, IC, NORM, and FSET. If no parameters are specified, ASKIP and 
NORM are assumed. If any. parameter is specified, UNPROT, NORM, and 
alphameric are assumed for any field unless overridden by a specified 
parameter. 

The ASKIP, PROT, UNPROT, and NUM attributes are used to describe 
the capability of the field to receive data. Fields with the ASKIP 
attribute imply the PROT attribute; the cursor automatically skips over 
the field. Data cannot be keyed into an ASKIP field. The PROT 
attribute is similar to the ASKIP attribute except that no automatic 
skipping of the field by the cursor occurs. The UNPROT attribute allows 
a field to be keyed; the NUM attribute ensures that the data entry 
keyboard is set to numeric shift for this field unless the operator 
pressed the alpha shift key. The NUM attribute also prevents entry 
of non-numeric data if the keyboard numeric lock feature is installed. 
The ASKIP, PROT, and UNPROT attributes are mutually exclusive. 

The BRT, NORM, and DRK attributes specify high intensity, normal 
intensity, and non-display/non- print respectively. These attributes 
are mutually exclusive. 

The DET attribute specifies that a field is potentially 
pen-detectable. As required for a 3270 pen-detectable field, the first 
data character must be a "?", a ">", or a blank. See "IBM 3270 
Information Display System Component Description", form number 
GA27-27U9, for the functions of these characters and other requirements 
of pen-detectable fields. Note that a field which has the BRT attribute 
is always potentially pen-detectable to the 3270, but is not recognized 
as such by the Basic Mapping Support unless the DET attribute is also 
specified. DET and DRK are mutually exclusive options. For input map 
fields, DET and NUM are the only valid options (all others are ignored) . 
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An input DET field has a one-byte reserved data area which is set to 
X'OO' when the field is unselected, or X'FF' when the field is selected. 
No other data is supplied. 

The IC attribute indicates that the cursor is to be placed in the 
first position of this field. The IC attribute for the last field in 
the map for which it is specified is the one that takes effect. If 
the IC attribute is not specified for any fields, the default location 
is zero. Specifying the IC attribute with the ASKIP attribute or PROT 
attribute causes the cursor to be placed in an unkeyable field. The 
FSET (field set) attribute specifies that this field should have the 
modified data tag (MDT) set on when the field is sent out to the 3270. 
This causes the 3270 to treat the field as if it had been modified, 
meaning that on a subseguent read from the terminal, this field is read 
in even though the field may not have been modified. This facility is 
useful for providing duplicate information or constant information from 
the screen as input. Note that the MDT remains on until the field is 
rewritten or until an input/output map reguest (for example, DFHMDI 
CTRL=FRSET or DFHBMS CTRL=FRSET) causes MDT's to be reset. 

JUSTIFY: This operand is used to specify the format of an input field. 
Normally, input fields are left- justified (JDSTIFY=LEFT) , and, if the 
data area is not filled, trailing blanks are inserted (JUSTIFY=BLANK) . 
However, numeric fields are often easier to manipulate if they are 
right- justified (JDSTIFY=RIGHT) and are preceded by zeros 
(JUSTIFY=ZERO) . Note that LEFT and RIGHT are mutually exclusive 
parameters, as are BLANK and ZERO. 

In the absence of certain of these parameters, the following is 
assumed: 



SPECIFIED 


ASSUMED 


LEFT 


BLANK 


RIGHT 


ZERO 


BLANK 


LEFT 


ZERO 


RIGHT 



If the JUSTIFY operand is omitted, the following is assumed: 

SPECIFIED ASSUMED 

NUM attribute RIGHT, ZERO 
Other than NUM 

attribute LEFT, BLANK 

INITIAL: This operand is used only in output map field descriptions 
to supply constant or default data for a field. If the name field of 
the DFHMDF macro instruction is not used, the user-written application 
program cannot access the output field map to alter the data or its 
attributes. If the name field of the DFHMDF macro instruction is used, 
the INITIAL data is always in the field but is overlayed by any data 
supplied by the user under this name field specification. For fields 
with the DET attribute, initial data that begins with a blank character, 
»?", or ">" should be supplied. 

GRPNAME: This operand is used to generate symbolic storage definitions 
and to combine individual fields under one group name by specifying 
the group name for each of the fields in the group. The fields 
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composing a group must be consecutive (contiguous) . Each DFHMDF macro 
instruction that names a field that is to belong to the group must 
include the GRPNAME operand specifying the common group name. For 
example: 



MAPX 


DFHMDI TYPE=DSECT,. 


FLD1 


DFHMDF 




LENGTH=20, 




POS=10, . . . 


GRPFLDA 


DFHMDF 




LENGTH=20, 




P0S=81, 




GRPNAME=GRP1,. .. 



LOCATE FIRST FIELD OF GROUP * 



GRPFLDB DFHMDF 

LENGTH=20, 
POS=101, 
GRPNAME=GRP1,. . . 



LOCATE SECOND FIELD OF GROUP * 

* 



FLD2 DFHMDF 

LENGTH=15, 
POS=161,... 



In the above example, if DFHMDI TYPE=DSECT, MODE=IN is specified, 
the generated names are FLD1I, GRP1I, GRPFLDAI, etc,; if DFHMDI 
TYPE=DSECT,MODE=OUT is specified, the generated names are FLD10, GRP10, 
GRPFLDAO, etc. These generated names must be used within the 
application program to reference the fields. 

A group of fields exists as a single field on the 3270; the 
individual field names (specified in the name field of the DFHMDF macro 
instruction) provide the user with access to portions of the complete 
3270 field. 

Fields coded without a group name entry are considered to be group 
fields consisting of a single entry. 

An entry with a group name but no field name results in an error 
condition. 



ONLINE MAP INVOCATION 

Online mapping operations are reguested by issuing the DFHBMS macro 
instruction. Basic Mapping Support (BMS) performs any reguired 
input/output operations via Terminal Control. The data returned from 
an input mapping operation is in TIOA format; the address of this TIOA 
is found at TCTTEDA. 

For an output mapping operation, if DATA=YES or DATA=ONLY, the 
application programmer must first have obtained, via Storage Control, 
a TIOA large enough to contain the symbolic storage definition of the 
map being used. Any fields not reguiring data to be passed to the 
mapping operation must be set to nulls (X'00*); this is best achieved 
through use of the INITIMG=00 operand of the DFHSC TYPE=GETMAIN macro 
instruction. Before issuing the DFHBMS macro instruction, the address 
of the TIOA must have been placed at TCTTEDA. 

The following BMS services are available through use of the DFHBMS 
macro instruction: 

1. Input - BMS performs a READ/WAIT via Terminal Control and maps 
the data (under control of the input map) into TIOA format. 
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2. Output - BMS converts the TIOA to 3270 data stream format, merges 
fields from the map (if desired), schedules a write operation, 
and waits for completion (if requested) . 

3. Map - BMS maps, upon request, any 3270 input TIOA into a mapped 
TIOA. 

The following operands can be included in the DFHBMS macro 
instruction: 

DFHBMS TYPE= (IN, OUT,ERASE, WAIT, SAVE, MAP) , * 

MAP='map name 1 , YES, * 

DATA=N0, YES, ONLY, * 

CTRL= (PRINT, L40,L64 r L80,HONEOM,FREEKB, ALARM, FRSET) , * 

CURSOR=number,YES, * 
MAPADR=symbolic address, YES 

TYPE: This operand is used to specify the type of mapping operation 
and to request screen erase and/or write synchronization in connection 
with an output operation. 

TYPE=IN specifies an input mapping operation. Input is accepted 
from the terminal via a Terminal Control READ/WAIT request. The input 
data is then mapped into the TIOA and made available to the application 
program by placing the TIOA address at TCTTEDA. 

After return is made to the application program from this macro 
operation, the fields entered are available to the application program 
under the symbolic names specified in the name fields of the input map 
DFHMDF macro instructions, with the letter "I" suffixed to correspond 
to the name CICS generates in the DSECT expansion. 

TYPE=OUT specifies an output mapping operation. The output TIOA 
(addressed at TCTTEDA by the user) is converted to a 3270 data stream 
and is written to the terminal. 

TYPE= (ERASE, OUT) is used to specify that the screen is to be erased 
before the output map is transmitted. 

TYPE= (OUT, WAIT) is used to specify that the output operation is to 
be synchronized with the completion of a write request. Since a wait 
is automatically issued in response to a read request, the 
TYPE= (IN, WAIT) specification is unnecessary. 

Note:. Multiple writes without wait may cause unpredictable results. 

TYPE=MAP specifies an operation similar to an input mapping operation 
(TYPE=IN) except that a Terminal Control read is not performed. If 
TYPE=MAP is specified, the user must have placed at TCTTEDA the address 
of the input TIOA containing 3270 data to be mapped. An example is 
the initial TIOA given to a transaction upon entering a transaction 
code. 

TYPE=SAVE may be specified with any use of the OUT parameter to 
indicate that the TIOA (addressed by TCTTEDA at the time the DFHBMS 
macro instruction is issued) is not to be freed. 

MAP: This operand is used to specify the name of the map to be used 
for input or output operations. The map must reside in the CICS program 
library and must have a corresponding entry in the Processing Program 
Table (PPT) . 
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MAP='map name 1 specifies the one- to seven-character name of the 
map to be used. 
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MAP=YES indicates that the user has placed at TCABMSMN the 
seven-character name of the map. If the name contains fewer than seven 
characters, it must be left justified and padded with blanks to seven 
characters. 

DATA: Applicable only to output mapping operations, this operand is 
used to specify one of three output mapping functions: (1) write only 
default data, (2) merge default fields with user fields, or (3) write 
only user data. If this operand is not specified, DATA=NO is assumed. 
no user data stream to be mapped into this output map description. 
(The user has not specified a TIOA.) Only the initial data (and/or 
default data) specified for the output map fields is transmitted to 
the terminal. 

DATA=YES indicates that data specified in the user's TIOA (the 
address of which is at TCTTEDA) is to be merged with the data in the 
output map. Data in the TIOA overrides the initial data and/or field 
characteristics in the output map. 

DATA=ONLY specifies that no initial fields are to be written; only 

the data supplied in the user's TIOA is to be written. No attribute 

bytes are sent from the map to the terminal. Only attributes specified 

by the user as "fieldname. A" or "groupname. A" are transmitted. 

CTRL: Used in conjunction with the TYPE=OUT operand, this optional 
operand is used to temporarily override control functions specified 
for a particular output map. This operand is effective as a temporary 
override only for this output request. 

CTRL=PRINT, CTRL=L40, CTRL=L64, CTRL=L80, and CTRL=HONEOM are options 
•that relate exclusively to the printer functions. CTRL=PRINT must be 
'specified if the printer is to be started; otherwise, the data is sent 
to the printer buffer but is not printed. CTRL=L40, CTRL=L64, CTRL=L80, 
and CTRL=HONEOM are mutually exclusive options that control the line 
length on the printer. The L40, L64, and L80 parameters force a 
carriage return/line feed at the end of their specified numbers of 
characters. CTRL=HONEOM causes the printer to honor all new line (NL) 
characters and the first end-of-message (EH) character in the data 
stream. If the NL character is omitted, a carriage return/line feed 
occurs at the physical end of the carriage or at the right margin stop, 
whichever is encountered first. 

When a data entry key is used by the 3270 operator, the keyboard is 
inhibited from entering further data. CTRL=FREEKB specifies that the 
keyboard should be unlocked when this map is written out. 

CTRL=ALARM is used to activate the 3270 audible alarm special 
feature. 

CTRL=FRSET specifies that the modified data tag is to be reset to 
the "not modified" condition on all fields. 

CURSOR: Applicable only to output mapping operations, CURSOR=number 
is used to position the cursor at a particular position on the screen 
upon completion of a WRITE. Any integral value in the range 0-1919 
may be specified, depending upon the screen size of the 3270 being 
used. This operand is effective as a temporary override only for this 
output request. 

CURSOR=YES indicates that the application programmer has previously 
specified the desired cursor position at TCABMSCP. 
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MAPADR: Restricted to application programs coded in Assembler language, 
this optional operand is used to specify the address of a user-coded 
map. This operand allows maps to be coded within the user-written 
application program. 

MAPAD'R=YES is used by the Assembler language programmer to indicate 
that the address of the map has been placed at TCABMSMA. 

Note: In the case of the C1CS/DOS-ENTRY system, the MAPADR operand 

must not specify any address within the limits of the program. 
Instead, the user must obtain an area of main storage via a 
Storage Control GETMAIN macro instruction and then move the map 
to this area. 

Specifying Ma ps for 3270 Basic Mapping Support 

The map used for input or output operations must be specified for 
BMS. If the user has placed the map in the CICS program library, the 
user must use the MAP= * mapname' specification, or, if preferred, the 
user may place the seven-character name of the map at TCABMSMN and 
specify MAP=YES. 

Assembler language programmers may "hard code" maps in their program 
and place the address of the map at TCABMSMA and code MAPADR=YES. If 
desired, the user may code MAPADR=symbolic address, where address is 
the label of the hard-coded map. Caution must be exercised when BMS 
is invoked and MAPADR is specified in the CICS/DOS-ENTRY system. (The 
address must be in subpool to avoid rollout.) 

Maps placed in the CICS program library are accessed by BMS through 
a Program Control LOAD. Therefore, the map name must be an entry in 
the Processing Program Table (PPT) . 

Implied Read/Write 

Input and output reguests result in a Terminal Control READ and 
WRITE, respectively. Therefore, the user is not reguired to code any 
Terminal Control macro instructions. 

Nothing prevents the user from alternately coding native mode and 
BMS operations. If desired, BMS will map a native mode input TIOA by 
reguesting only a MAP operation. However, for input to a non-formatted 
buffer with no MAP operation reguested, mapping will not be performed 
and a NULL TIOA will be returned. 

No te: The read that contains the transaction code and causes initiation 
of the transaction is a native 3270 data stream. The MAP reguest 
may be used to convert this TIOA to a mapped TIOA. 

Using the DFHBMS Ma££2 Instr uct ion 

Regardless of the programming language used (Assembler language, 
ANS COBOL, or PL/I) , the same form of the DFHBMS macro instruction is 
used to reguest a mapping operation. In the case of ANS COBOL and 
PL/I, the CICS Preprocessor resolves the macro instruction and expands 
it into the statements reguired to invoke the mapping function. 

Terminal input, which causes a task to be initiated, is stored in 
the task»s initial TIOA as a native mode 3270 data stream. By 
reguesting a MAP operation via DFHBMS, the application program is given 
the capability to map this TIOA into a particular input format. The 
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Standard' Attribute List and Printer Control Characters (DFHBMSCA) 

The application programmer can obtain a set of commonly used 3270 
field attributes and printer control characters by copying DFHBMSCA 
into his program. DFHBMSCA consists of a set of EQU statements in the 
case of Assembler language, a set of 01 statements in the case of ANS 
COBOL, and DECLARE statements defining elementary character variables 
in the case of PL/I. One possible use for DFHBMSCA is for the purpose 
of temporarily changing attribute characters in a map. 

Listed below are the field attributes/printer control characters 
and corresponding symbolic names. 



SYMBOLIC NAME 

DFHBMPEM 
DFHBMPNL 
DFHBMASK 
DFHBMUNP 
DFHBMUNN 
DFHBMPRO 
DFHBMBRY 
DFHBMDAR 
DFHBMFSE 
DFHBMPRF 
DFHBMASF 
DFHBMASB 



FIELD ATTRIBUTE/PRINTER CONTROL CHARACTER 

3270 Printer end of message 

3270 Printer new line symbol 

Autoskip 

Unprotected 

Unprotected and numeric 

Protected 

High Intensity 

Dark, nonprint 

MDT on 

Protected and MDT on 

Autoskip and MDT on 

Autoskip and high intensity 



These attributes cannot be combined by the application programmer 
in any manner. If any combinations other than those listed are 
reguired, the application programmer must either use the ATTRB operand 
of the DFHMDF macro instruction to obtain the desired combinations or 
must assume responsibility to generate new attribute combinations 
offline. 

Standard Attention Identifier List (DFHAID) 

To test the method of initiating an incoming READ from the 3270 
Information Display System, the application programmer is provided with 
a set of 3270 attention identifiers (single-character variables called 
AID'S) that can be used to test the value at TCTTEAID. He can obtain 
this set of attention identifiers by copying DFHAID into his program. 

DFHAID consists of a set of EQU statements in the case of Assembler 
language, a set of 01 statements in the case of ANS COBOL, and DECLARE 
statements defining elementary character variables in the case of PL/I. 
Listed below are the symbolic names for the attention identifiers and 
the corresponding 3270 function. 



SYMBOLIC NAME 



3270 FUNCTION 



DFHENTER 

DFHCLEAR 

DFHPEN 

DFHPA1 

DFHPA2 

DFHPA3 

DFHPF1 



Enter key 

Clear key 

Immediately detectable field 

PA1 key 

PA2 key 

PA3 key 

PF1 key 



DFHPF12 



PF12 key 
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BMS TIO A Specification 

Depending on the programming language used, the BMS symbolic storage 
definition of the TIOA must be provided in the application program as 
shown in the following examples. Note that mapnamel, mapname2, and 
mapname3 in these examples are the names of modules that contain the 
assembly of a BMS symbolic storage definition (TYPE=DSECT) . 

1. Assembler language COPY statements. 

COPY DFHTIOA 
COPY mapnamel 



COPY mapname2 

COPY mapname3 

2. ANS COBOL COPY statements for each symbolic storage definition 

LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS. 



01 DFHCSADS COPY DFHCSADS. 
01 DFHTCADS COPY DFHTCADS. 
01 DFHTIOA COPY DFHTIOA. 
01 name COPY mapnamel. 
01 name COPY mapname2. 
01 name COPY mapname3, 

3. PL/I INCLUDE statements. 

%INCLUDE DFHTIOA; 
^INCLUDE mapnamel; 
%INCLUDE mapname2; 
%INCLUDE mapname3; 

In addition to providing the BMS symbolic storage definition for 
the TIOA, the application programmer must establish addressability for 
this storage definition. Depending on the programming language used, 
this is accomplished as follows: 

1. Assembler language ORG statement immediately preceding the 
symbolic storage definition for each map, starting with the 
second map. For example: 

COPY DFHTIOA 

COPY mapnamel 

OEG TIOADBA 

copy mapname2 

ORG TIOADBA 

COPY mapname3 



DFHSC TYPE=GETMAIN, * 

NUMBYTE=120, * 

CLASS=TERMINAL, * 

INITIMG-00 

L TIQABAR,TCASCSA ESTABLISH TIOA ADDRESSABILITY 
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2. ANS COBOL 02 statements immediately following the COPY statement 
for the Linkage Section Base Locator (BLL) . These 02 statements 
must be coded in the same order as the corresponding 01 
statements coded subsequently. For example: 

LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS. 



02 TI0ABAR PICTURE S9 (8) COMPUTATIONAL. 
02 MAPBASE1 PICTURE S9(8) COMPUTATIONAL. 
02 MAPBASE2 PICTURE S9 (8) COMPUTATIONAL, 
02 MAPBASE3 PICTURE S9 (8) COMPUTATIONAL, 



01 DFHTI0A COPY DFHTI0A. 

01 name COPY mapnamel . 

01 name COPY mapname2. 

01 name COPY mapname3. 



PROCEDURE DIVISION. 



DFHSC TYPE=GETMAIN, * 

NUMBYTE=120, * 

CLASS=TERMINAL, * 

INITIMG=00 

MOVE TCASCSA TO TIOABAR. 

ADD 12 TIOABAR GIVING MAPBASE1. 

ADD 12 TIOABAR GIVING MAPBASE2. 

ADD 12 TIOABAR GIVING MAPBASE3. 

3. PL/I based pointer variable (BMSMAPBR) . For example: 
DCL TIOABAA FIXED BINARY (31,0) BASED (TIOABAB) ; 



%INCLUDE DFHTIOA; 

^INCLUDE mapnamel; /*EACH OF THESE MAPS IS*/ 

%INCLUDE mapname2; /*BASED ON THE SAME POINTER*/ 

^INCLUDE mapname3; /*VARIABLE - BMSMAPBR*/ 



DFHSC TYPE=GETMAIN, * 

NUMBTYE=120, * 

CLASS=TERMINAL, * 

INITIMG=00 

TIOABAR=TCASCSA; 

TIOABAB=ADDR (TIOABAR) ; 

TIOABAA=TlOABAA+12; 

BMSMAPBR=TIOABAR; 

Examples 2l the Use of BMS 

The examples in this section are based on a fairly simple screen 
exercising problem and are intended to show the results of generating 
symbolic storage definition maps. 
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In the examples, an input symbolic storage definition and an output 
symbolic storage definition are illustrated for each of the programming 
languages supported by CICS: Assembler language, ANS COBOL, and PL/I. 
Each of these examples is generated from the screen definition of the 
first example; only the initial DFHMDI entry is changed. 

SAMPLE DFHMDI TYPE=DSECT,LANG=ASM , MODE=IN, TERM=3270, CTRL=FREEKB 

DFHMDF POS=0,LENGTH=17,INITIAL=»ENTER YOUR NAME — • 
NAME DFHMDF P0S=1 8 ,LENGTH=1 8 , ATTRB= (IC , UNPROT) 

DFHMDF POS=40,LENGTH=17,INITIAL=« WHAT IS THE DATE?' 
MONTH DFHMDF P0S=58, LENGTH=2 , INITIAL= • MM « , GRPNAME=DATE 
DAY DFHMDF POS=60 , LENGTH=2, INITIAL= f DD • , GRPN AME=DATE 
YEAR DFHMDF POS=62 ,LENGTH=2, INITIAL= • YY ' , GRPN AME=DATE 

DFHMDF POS=80,LENGTH=26,INITIAL=' SELECT YOUR FAVORITE COLOR' 
BLUE DFHMDF POS = 1 20 ,LENGTH=9 , ATTRB=DET, INITIAL= • ?)JBLUE)W 
RED DFHMDF POS=1 3 1 , LENGTH = 8, ATTRB=DET, INITIAL= • ?#RED)W 
AMBER DFHMDF POS=1 4 1 ,LENGTH=1 , ATTRB=DET , INITIAL= « ?#AMBERJW 

DFHMDF POS=160,LENGTH=19, ATTRB= (PROT,BRT) , 
INITIAL='N0W HIT A PF KEY... 1 
ERROR DFHMDF POS=240 ,LENGTH=1 9, ATTRB=DRK, 
INITIAL=' SORRY, TRY AGAIN « 

DFHMDI TYPE=FINAL 

END 

Example 1. Symbolic storage definition input 
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SAMPLEI 


DS 


OC 
SPACE 


2 






NAMEL 


DS 


H 




DATA 


LENGTH 


NAMEI 


DS 


CL18 
SPACE 


2 


DATA 


OR FLAG 


DATEL 


DS 


H 




DATA 


LENGTH 


DATEI 


DS 


OC 




GROUP DATA 






SPACE 


2 










SPACE 


2 






MONTHI 


DS 


CL2 

SPACE 


2 


DATA 




DAYI 


DS 


CL2 

SPACE 


2 


DATA 




YEARI 


DS 


CL2 

SPACE 


2 


DATA 




BLUEL 


DS 


H 




DATA 


LENGTH 


BLUEI 


DS 


CL1 

SPACE 


2 


DATA 


OR FLAG 


REDL 


DS 


H 




DATA 


LENGTH 


REDI 


DS 


CL1 

SPACE 


2 


DATA 


OR FLAG 


CLUEI 


DS 


H 




DATA 


LENGTH 


CLUEI 


DS 


CL5 

SPACE 


2 


DATA 


OR FLAG 


AMBERL 


DS 


H 




DATA 


LENGTH 


AMBEEI 


DS 


CL1 

SPACE 


2 


DATA 


OR FLAG 


ERRORL 


DS 


H 




DATA 


LENGTH 


ERRORI 


DS 


CL19 




DATA 


OR FLAG 


* * * END OF MAP 


DEFINITION * * 


* 






DFHBMSKS 







Example 2. Symbolic storage definition using LANG=ASM, MODE=IN 
specification 
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SAMPLEO DS OC 

SPACE 

NAMEA DS C 
DS C 

MMEO DS CL18 
SPACE 
SPACE 

DATEA DS CL1 
DS CL1 

DATEO DS OC 

SPACE 

MONTHO DS CL2 

SPACE 

DAYO DS CL2 

SPACE 
DS CI2 



YEARO 



ELUEA 



BLUEO 



REDA 



REDO 



CLUEA 



CLDEO 



AMBERA 
AMBERO 



ERROR A 



ERRORO 



DS 
DS 



SPACE 

SPACE 

C 

C 
DS CL5 

SPACE 

SPACE 
DS C 
DS C 
DS CI5 

SPACE 

SPACE 
DS C 
DS C 
DS CL5 

SPACE 

SPACE 

C 

C 
DS CL5 

SPACE 

SPACE 

C 

C 
DS CL19 

SPACE 



DS 
DS 



DS 
DS 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



USER ATTRIBUTE 
RESERVED 
GROUP START 

DATA PTELD 

DATA FIELD 

DATA FIELD 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



USER ATTRIBUTE 
RESERVED 
DATA FIELD 



* * * END OF MAP DEFINITION * * * 
DFHBMSKS 



Example 3. Symbolic storage definition using LANG=ASM # MODE-OUT 
specification 
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01 SAMPLEI SYNCHRONIZED. 

02 NAMEL COMP PIC S9 (4) . 
02 NAMEI PIC X(18) . 
02 DATEL COMP PIC S9 (4) . 
02 DATEI. 

03 MONTHI PIC X(2) . 

03 ran pic x(2) . 

03 YEARI PTC X(2) . 

02 BLDEL COMP PIC S9(4). 

02 BLUEI PIC X(1). 

02 REDL COMP PIC S9 (4) . 

02 REDI PIC X(1) . 

02 CLUEL COMP PIC S9 (4) . 

02 CLUEI PIC X{5) . 

02 AMBERL COMP PIC S9 (4) . 

02 AMBERI PIC X(1) . 

02 ERROR! COMP PIC S9 (4) . 

02 ERRORI PIC X(19) . 

Example 4. Symbolic storage definition using LANG=COBOL,MODE=IN 
specification 



01 SAMPLEO SYNCHRONIZED. 
02 NAMEA PICTURE X. 
02 FILER PICTURE X. 
02 NAMEO PICTURE X(18). 
02 DATEA PICTURE X. 
02 FILLER PICTURE X. 
02 DATEO. 

03 MCNTHO PICTURE X (2) . 

03 DAYO PICTURE X (2) . 

03 YEARO PICTURE X (2) . 
02 BLUEA PICTURE X. 
02 FILLER PICTURE X* 
02 BLUEO PICTURE X(5). 
02 REDA PICTURE X. 
02 FILLER PICTURE X. 
02 REDO PICTURE X (5) . 
02 CLUEA PICTURE X. 
02 FILLER PICTURE X. 
02 CLUEO PICTURE X(5). 
02 AMBERA PICTURE X. 
02 FILLER PICTURE X. 
02 AMBERO PICTURE X{5). 
02 ERRORA PICTURE X. 
02 FILLER PICTURE X. 
02 ERRORO PICTURE X(19). 

Example 5. Symbolic storage definition using LANG=COBOL, MODE=OUT 
specification 
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DECLARE 1 SAMPLEI ALIGNED BASED (BMSMAPBR) , 
2 NAMEL FIXED BINARY (15,0) , 
2 NAMEI CHARACTER (18) , 
2 DATEL FIXED BINARY (15,0), 
2 DATEI, 

3 MONTHI CHARACTER (2) , 

3 DAYI CHARACTER (2) , 

3 YEARI CHARACTER (2) r 
2 BLUEL FIXED BINARY (15,0) , 
2 BLUEI CHARACTER (1), 
2 RED! FIXED BINARY (15,0), 
2 REDI CHARACTER (1) , 
2 CLUEL FIXED BINARY (15,0) , 
2 CLflEI CHARACTER (5) , 
2 AMBERL FIXED BINARY (15,0), 
2 AMBERI CHARACTER (1), 
2 ERRORL FIXED BINARY (15,0) , 
2 ERROR! CHARACTER (19), 
2 FILLC030 CHARACTER (1) , 
/* END OF MAP DEFINITION */ 



Example 6. Symbolic storage definition using LANG=PL1 r MODE=lN 
specification 



DECLARE 1 SAMPLEO ALIGNED BASED 
2 NAMEA CHARACTER (1) , 
2 FITL0008 CHARACTER (1) 
2 NAMEO CHARACTER (18), 
2 DATEA CHARACTER (1), 
2 FILL0014 CHARACTER (1) 
2 DATEO, 

3 MONTHO CHARACTER (2) 
3 DAYO CHARACTER (2) , 
3 YEARO CHARACTER (2) , 
2 3LUEA CHARACTER (1) , 
2 FILL0029 CHARACTER (1) 
2 BLDEO CHARACTER (5) , 
2 REDA CHARACTER (1) , 
2 FIIL0035 CHARACTER (1) 
2 REDO CHARACTER (5) , 
2 CLOEA CHARACTER (1), 
2 *TIL0033 CHARACTER (1) 
2 CLUEO CHARACTER (5) , 
2 AMBERA CHARACTER (1), 
2 FTLL0041 CHARACTER (1) 
2 AMBEEO CHARACTER (5) , 
2 ERRORA CHARACTER (1) , 
2 FTIL0047 CHARACTER (1) 
2 ERRORO CHARACTER (19), 
2 FIIL0050 CHARACTER (1) 
/* END OF MAP DEFINITION */ 



(BMSMAPBR) 



Example 7. Symbolic storage definition using LANG=PL1,MODE=OUT 
specification 
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PBOGRAM TESTING AND DEBUGGING 



Testing in the information system environment has always been 
difficult. The information system, including the operating system, 
CICS, and the user's application programs, must be responsive to many 
factors concurrently. The eguipment configuration includes many lines 
and terminals through which reguests for varied services are coming 
constantly on a random, nonscheduled basis. The precise relationship 
cf all programs and data set (file) activity generated from the terminal 
inputs is never the same from one moment to the next. 

Even at the simplest level of program testing, the implementer faces 
problems. He cannot efficiently test his program from a terminal which 
reguires that all test data be keyed into the system each time that 
he requires a test shot. He cannot easily retain a backlog of proven 
test data and quickly test his programs through the key-driven terminal 
as program changes are made. 

CICS allows the application programmer to begin testing his programs 
without requiring the use of a telecommunication device. It is possible 
to specify through the Terminal Control Table that sequential devices 
be used as terminals. At the same time, the Terminal Control Table 
can include references to the other terminals on the system. The 
seguential devices are the card reader, line printer, disk, and magnetic 
tape. In fact, a Terminal Control Table can include combinations of 
sequential devices such as: card reader and line printer, one or more 
disk data sets as input, one or more disk data sets as output. The 
same table can also include references to the other terminals on the 
system. 

The input data must be prepared in the form that it would come from 
a terminal. A transaction identification must appear in the first 
four positions of the first input for a transaction, and, if a 
sequential device is being used as a terminal, a 0-2-8 punched card 
code or the equivalent must fellow the input message. The input is 
processed sequentially and must be unblocked. The Sequential Access 
Method (SAM) is used to read and write the necessary inputs and outputs. 
The operating system utilities can be used to create the input data 
sets and print the output data sets. 

Consequently, it is possible to prepare a stream of transaction 
test cases to do the basic testing of a program module. As the testing 
progresses, the user would want to generate additional transaction 
streams to validate the multiprogramming capabilities of his programs 
or to allow different transaction test cases. to be run concurrently. 

User-written application programs can make use of the facilities 
of Dump Control and Trace Control to capture the status of the programs 
during testing. The Dump Control output is printed by using the CICS 
Dump Utility program. For a description of the Dump Control facilities, 
see "Dump Services". 

At some point in testing, it is necessary to use the 
telecommunication devices to ensure that the transaction formats are 
satisfactory, that the terminal operational approach is satisfactory, 
and that the transactions can be processed on the terminal. The 
Terminal Control Table can be altered to contain more and different 
devices as the testing requirements change. 

When the testing has proven that multiple transactions can be 
processed concurrently and the necessary data sets (actual or duplicate) 
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for online operation are created, the user begins testing in a 
controlled environment with the telecommunication devices. In the 
controlled environment, the business activity should represent all 
functions of the eventual system, but be on a smaller and a measurable 
scale. For example, a company whose information system will work with 
15 district offices would select one district office for the controlled 
test. During the controlled test, all transactions, data set activity, 
and output activity from the system would be closely measured. 

Testing is a continuing process; it is net complete when customer 
conversion occurs. The entire testing cycle is repeated as the 
applications are upgraded and new applications are added to the system. 

TJACE CONTROL FUNCTIONS 

The optional CICS Trace facility is designed as a debugging aid 
for the application programmer. This facility makes use of a Trace 
Table which is produced by requests for Trace Control services and 
which consists of standard and nonstandard entries. Standard entries 
are recorded in the table each time one of the following CICS macro 
instructions is issued by an application program or by a CICS management 
program: 

1. DFHKC (Task Control) 

2. DFHSC (Storage Control) 

3. DFHPC (Program Control) 

4. DFHIC (Interval Control) 

5. DFHDC (Dump Control) 

6. DFHFC (File Control) 

7. DFHTD (Transient Data Control) 

8. DFHTS (Temporary Storage Control) 

Each standard entry contains a unique ID and information which will 
aid the application programmer in determining where the macro 
instruction was issued and what type of request was made to the 
management program. Thus, without any additional programming, the 
application programmer is provided with a useful tool to aid in the 
debugging process. 

In addition, the application programmer may make direct, nonstandard 
entries in the Trace Table by using the DFHTR macro instruction in 
his application program. The user assigns his own identification and 
accompanying data for each trace entry. Thus, the user could define 
several unique trace entries and trace the logical path through a 
particular application or group of application programs. 

Trace Control is branched to by its requesting program and executes 
as a service routine under the requesting program* s TCA. Registers 
are saved and restored. Return is always made to the next sequential 
instruction in the requesting program once the requested service has 
been performed. 

If the user has generated the Trace feature in his system, he may 
dynamically control which trace entries are to be made in the table. 
Trace activity is controlled by two sets of flag bytes in the CSA 
(CSATRMF1 and CSATRMF2) and one flag byte in the TCA (TCATRMF) . The 
meaning of the individual bits of the flag bytes is as follows: 
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CJ ATRMF1 

Bit Mea nin g 

Master Flag - if off, no trace occurs. 

1 System Master Flag - if off, no system entries 
(ID 2C0-239) are traced. 

2 User Master Flag - if off, no user entries 
(ID 0-199) are traced. 

3-7 Reserved 

CSATRMF2 

Bit Meaning Trace ID 

On to trace Task Control macro instructions. X'FO 1 

1 On to trace Storage Control macro X'F1* 
instructions. 

2 On to trace Program Control macro ■X , F2' 
instructions. 

3 On to trace Interval Control macro J. 1 73* 
instructions. 

4 On to trace Dump Control macro instructions. X'F4 f 

5 On to trace File Control macro instructions. X'F5' 

6 On to trace Transient Data Control macro X'FS* 
instructions. 

7 On to trace Temporary Storage Control macro X'F7» 
instructions. 

Bit of the TCA flag byte (TCATRMF) is used only if the user master 
flag (X»20 f ) is off in the CSA flag byte CSATRMF1, If the user master 
flag is off, only those user entries that are issued by tasks with 
the TCA flag on are traced. 

The Trace Control macro instruction (DFHTR) is used to request any 
of the following services: 

1. Dynamically allow the Trace facility to begin logging appropriate 
entries into the Trace Table k . 

2. Dynamically cause the Trace facility to stop logging entries 
into the Trace Table. 

3. Dynamically cause a specified entry to be logged into the Trace 
Table. 

The following operands can be included in the DFHTR macro 
instruction: 

DFHTR TYPE=ON, * 

STYPE=SINGLE,ALL, (system symbol) , SYSTEM, DSER 

DFHTR TYPE=OFF, * 

STYPE=SINGLE,ALL, (system symbol) , SYSTEM, USER 

DFHTR TYPE=ENTRY, * 

STYPE=SYSTEM,USER, * 

lD=number, * 

DATA1=syabol, (symbol) , * 

RDATAl=register, (register) , * 

DATA2=symbol, (symbol) , * 

RDATA2=register, (register) , * 

DATA1TP=HBTN,FBIN, CHAR, PACK, POINTER, * 
DATA2TP=HBIN,FBIN ,CHAR /PACK, POINTER 
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TRACE ON FUNCTION 

The ON function of Trace Control is used to dynamically allow the 
Trace facility to begin logging appropriate entries into the Trace 
Table. The application programmer invokes it by use of the 

DFHTR TYPE=ON r 

STYPE=SINGLE,ALL, (system symbol) ,SYSTEM,USER 

macro instruction. 

STTPE: Identifies which of the types of entries are to be traced. 
The meaning of each of the parameters is as follows: 

1. SINGLE, specifies that the trace capability is to be turned 
on for the single transaction issuing the DFHTR macro 
instruction. STYPE=SINGLE has no effect unless the USER 
designation has been turned off. 

2. ALL, specifies that the complete trace function is to be turned 
on. 

3. System symbol, specifies one or more of the valid system 
functions. A special Trace Table entry is created each time 
one of the CICS macro instructions is issued. This parameter 
allows the user to selectively turn on the appropriate system 
macro trace facility. The valid system symbols are: 

KC Task Control (DFHKC) 

SC storage Control (DFHSC) 

PC Program Control (DFHPC) 

IC Interval Control (DFHIC) 

DC Dump Control (DFHDC) 

FC File Control (DFHFC) 

TD Transient Data Control (DFHTD) 

TS Temporary Storage Control (DFHTS) 

4. SYSTEM, specifies that the trace capability is to be turned 
on for all entries made from within CICS, excluding the CICS 
macro entries controlled by the CSATRMF2 flag byte. 

5. USER, specifies that the trace capability is to be turned on 
for all user entries. 



TRACE OFF FUNCTION 

The OFF function of Trace Control is used to dynamically cause the 
Trace facility to stop logging entries into the Trace Table. The 
application programmer invokes this function by issuing the 

DFHTR TYPE=OFF, 

STYPE=SINGLE,ALL, (system symbol) , SYSTEM, USER 

macro instruction. 

STYPE: Indicates which of the types of entries are not to be traced. 
Each of the parameters has the same meaning as when used with the DFHTR 
TYPE=ON macro instruction. 
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TRACE ENTRY EDUCTION 

The ENTRY function of Trace Control is used to dynamically cause 
a specified entry to be logged into the Trace Table if the Trace 
facility has been turned on for that type of entry. The application 
programmer invokes this function by issuing the 

DFHTR TYPE=ENTRY, * 

STYPE=SYSTEM,USER, * 

ID=nuraber, * 

DATA1=symbol, (symbol) , * 

RDATA 1=register, (register) , * 

DATA2=symbol, (symbol) , * 

RDATA2=register, (register) , * 

DATA 1TP=HBIN ,FBIN,CHAR, PACK, POINTER, * 
DATA2TP=HBIN,FBIN,CHAR, PACK, POINTER 

macro instruction. 

STYPE: Indicates whether this entry is a CICS entry or user entry. 

ID: Specifies the identification number to be used on this entry and 
must be coded as a self-defining term. The following range of numbers 
may be coded: 

0-199 with STYPE=USER 
2^0-239 with STYPE=SYSTEM 

Numbers 240-253 are reserved for system macro trace entries. 254 and 
255 indicate the TYPE-ON and TYPE=0FF entries, respectively. 

EATA1: Specifies the address of the data to be placed in the first 
data field of the table entry. If parentheses are used, the specified 
address is an address of an area that contains the address of the data. 

RDATA 1: Specifies the register whose contents are to be placed in 

the first data field of the table entry. If parentheses are used, 
the specified register contains the address of the data. RDATA 1 and 
EATA1 are mutually exclusive. 

DATA2: Similar to DATA 1 except that it is used for the second data 
field of the Trace Table entry, 

RDATA2: Similar to RDATA 1 except that it is used for the second data 
field of the Trace Table entry. 

DATA1TP: Valid only for ANS COBOL and PL/I programs, this operand 
specifies the format of the data to be placed in the first data field 
of the Trace Table entry. The default is DATA1TP=FBIN. 

The applicable keyword parameters are HBIN, FBIN, CHAR, PACK, and 
POINTER, and are used as follows: 
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Specification 
DATA1TP=HBIN 

DATA1TP=FBIN 

DATA1TP=CHAR 

DATA1TP=PACK 



Data F orma t 
Halfword, binary 

Fullword, binary 

1 to t characters 



1 to 4 bytes, 
packed decimal 



"Field Definition 



COBOL: 
PL/I : 

COBOL: 
PL/I : 

COBOL: 
PL/I: 

COBOL: 

PL /I: 



9(4) COMP 
BIN FIX (15) 

9(B) COMP 
BIN FIX (31) 

X(4) 
CHAR (4) 

9(7) COMP-3 
DEC FIX (7) 



DATA1TP=P0INTER PL/I pointer 

variable 



BATA2TP: Similar to DATA1TP except that it is used for the second 
data field of the Trace Table entry. The default is DATA2TP=FBIN. 

TRACE TABLE 

The optional CICS Trace Table consists of a variable number of 
fixed-length entries and may be generated during system generation. 
It is used to trace the logical flow of transaction activity through 
the system. Following generation, the trace feature may be invoked 
during system initialization by specifying the number of Trace Table 
entries to be other than zero. If the Trace Table is invoked, the 
address of the table is placed in the CSA at CSATRTBA. 

Each entry in the table is a fixed 16 bytes in length, and is aligned 
on a doubleword boundary. The table is used in a wrap-around manner 
so that when the last entry is used, the next entry is placed at the 
beginning of the table. The first 16 bytes of the table are a control 
field for the balance of the table and contain the following 
information: 

MIM CONTENTS 

0-3 Address of the current entry 

4-7 Address of the beginning of the table 

8-11 Address of the end of the table 

12-15 Reserved 
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The format of the individual trace entry is: 
BYTES CONTENTS 

Trace identification of entry. 

1-3 Contents of register H at entry to the Trace program, 
or if the ID is X^O' through X'F?', it is the contents 
of register 14 at entry to the CICS management program 
concerned. 

H If the Trace ID is one of the following, this field 

contains the type of request code as it relates to the 
applicable CICS management program. 

Program Trace ID 

Taslc Control X'F0» 

Storage Control X'FT 

Program Control X'F2* 

Interval Control X'F3» 

Dump Control X'F4» 

File Control X»F5» 

Transient Data Control X'TS 1 

Temporary Storage Control X'F7» 

CICS/OS-DL/I Interface X«F8» 

5-7 Transaction identification as found in the CICS control 
section of the TCA. This identification is unique for 
each transaction. 

8-11 Data field 1. 
12-15 Data field 2. 

The CICS Trace Table entries are indicated in Tables 1-10 which 
follow. (For a discussion of the CICS/OS-DL/I Interface Trace Table 
entries, see the section "Requesting Data Language/I Services".) 



220 



Table 1. Task Control 



i I | TYPE | | 

|TRACE| l OF | | 

! ID {REGISTER 14 | REQ1 TRANSACTION ID | 



FIELD A 



I 

FIELD B | 



X«F0» 



REQUEST CODE 
IIOM TCATCTR 

X'80* (DETACH) 

X'40 1 (WAIT) 



X^O' (CHAP) 
XMU» (AVAIL) 

X»12» (SCHEDULE) 



XM1' (Conditional 
ATTACH) 



X'10» (ATTACH) 

X«08 f (RESUME) 

X»04« (SUSPEND) 

X«02« (DEQUEUE) 

X'CV (ENQUEUE) 



Not used 

Dispatch 
Control 
Indicator 
TCATCDC 

New priority 
TCATCDP 

Facility 

Control 

Address 

Terminal ID or 
AID address 
TCAKCTA 

Facility 

Control 

Address 

Facility 

Control 

Address 

TCA (TXA) 
address of 
resumed 
transaction 

Not used 

Queue name 
address TCATCQA 

Queue name 
address TCATCQA 



Not used 

Event 
Control 
Address 
TCATCEA 

Not used 



Not used 



Transaction 
ID TCAKCTI 



Transaction 
ID TCAKCTI 



Transaction 
ID TCAKCTI 



Not used 

Not used 
Not used 

Not used 
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Table 2. Storage Control 



|| J TYPE | | 

|TRACE| I OF | | 

f ID {REGISTER 1U | REQ| TRANSACTION ID { FIELD A 



REQUEST CODE 
ZSOM TCASCTR 

Bit Condition 

1=GETMAIN 

1 1=FREEMAIN 



X«F1» 



Bjte 

Not used 



1 



Initiali- 
zation byte 
for GETMAIN 



1=Release all 

Terminal strg 2-3 Requested 

if bit 0=0 number of 

and bit 1=1 bytes 

1=Conditional 
GETMAIN if 
bit 0=1 and 
bit 1=0 



FIELD B 



Not used 



X»C8» 



X»C9' 



1=RELEASED (used 
by CICS to 
obtain initial 
storage cushion 
if bits 0, 1=0 

1=Conditional 2-3 Number of 
Storage is to bytes released 
be initialized following 

FREEMAIN 

0=Subpool 

1=Subpool 1 

0=Unchained 
storage 

1=Chained storage 

1=TCA type of 
storage 

1=Terminal type of 
storage 



Not used 



Not used 



0-3 Address off Storage 

main storage accounting 
acquired 

0-3 Address of Storage 

main storage accounting 
released 
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Table 3. Program Control 



I I 

|T"RACE| 

I ID | REGISTER 



| TYPE | | 

I OF | | 

1U| REQJ TRANSACTION ID | FIELD A 



FIELD B 



X»F2' 



REQUEST CODE 
FROM TCAPCTR 

X»90» (REFRESH - 

CICS/DOS-ENTRY 
only) 

X'84« (Conditional 
LOAD) 

X«60« (ABEND 

with dump) 

X«40» (ABEND 

without dump) 

X'10' (RETURN) 

X'08« (DELETE) 

X f 04» (LOAD) 

X«02« (XCTL) 

X'OV (LINK) 



PPT entry Not used 
address TCAPCTA 



Program name 
from TCAPCPI 

Abend code 
from TCAPCAC 

Not used 



Not used 
Not used 
Not used 



Not used Not used 
Not used Not used 
Program name from TCAPCPI 
Program name from TCAPCPI 
Program name from TCAPCPI 



'"able 4. Interval Control 



TRACE! 
! ID | REGISTER 



|TYPE| | 

| OF | | 

14| REQ1 TRANSACTION ID | 



FIELD A 



FIELD B 



X»F3» 



REQUEST CODE FROM 
3CATCTJ QR~TCAICRC 

X»1x« (GETIME) 



where "x" consists 
of the low-order 
four bits: 



Return time to 
user address 
TCAICDA 



Not used 
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Table 4. Interval Control (continued) 



I | | TYPE | 

|TRACE| J OF ( 

| ID |REGISTER 14| EEQj TRANSACTION ID 



FIELD A 



FIELD B I 



EEQOEST CODE FROM 
5£AICTR OR TCAICPC 

Jit Cond it ion 

4,5 Always zero 

6 0=Refresh CSA 

Time only 
1=Return time 
to user 

7 0=Binary format 
1=Packed format 

X'2x f (WAIT) 



X»3x« (POST) 



INTRVAL or 
TIME value 
(TCAICRT) 

INTRVAL or 
TIME value 
(TCAICRT) 



where "x" consists 
of the low-order 
four bits: 

Bii Condition 

4 0=INTRVAL parameter 

provided 

1=TIME parameter 
provided 

5 0=No Request 

ID provided 
1=User~provided 
Request ID 



6,7 Always zero 
X*4x« (INITIATE) 

X«5x' (PUT) 



INTRVAL or 
TIME value 
(TCAICRT) 

INTRVAL or 
TIME value 
(TCAICRT) 



where "x" consists 
of the low-border 
four bits: 

Bit Condition 

4 0=INTRVAL parameter 



Not used 



Not used 



Transaction 
ID (TCAICTI) 



Transaction 
ID (TCAICTI) 
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Table 4. Interval Control (continued) 



jTRACEl 

| ID [ REGISTER 



| TYPE | | 

| OP 1 | 

1^1 REQl TRANSACTION ID | FIELD A 



FIELD B 



REDDEST CODE FROW 
TCAICTR OR TCAICRC 

provided 
1=TIHE parameter 
provided 

5 0=No Request 

ID provided 
1=User-provided 
Request ID 

6 Always zero 

7 0=Non-terminal 

destination 
1=Terminal 
destination 

X'flx 1 (GET) 

where "x" consists 
of the low-order 
four bits: 

Sii Condition 

4,5 Always zero 

6 O=0ser-provided 

data address 
1=Return data 
address to user 

7 Always zero 

X'90» (RETRY) 

X*Fx« (CANCEL) 

where "x" consists 
of the low-order 
four bits: 

Jit Cond itio n 

4 Always Zero 

5 0=No Request 

ID provided 
1=Dser-provided 
Request ID 

6,7 Always zero 



User-provided 
data address 



Not used 



Not used 
Request ID 



Not used 
(TCAICQID) 
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Table 5. Dump Control 

I I |TYPE| I I | 

| TRACE | f OF | | J | 

| ID | REGISTER 14 | REQ| TRANSACTION ID | FIELD A | FIELD B | 

u , ; , , — i 

5I0JJEST CODE CONTENTS 

NOT USED FROM TCADCTR 

(see field A) (Bytes 2-^3 

not used) 

X»F4» TRANSACTION X'FEOO* Abend 

code 

CICS X'OOFF 1 

COMPLETE X'FEFF' 

PARTIAL 

TCA X'OOOO* 

SEGMENT X'0100' 

TRANSACTION X«0400* 

TERMINAL X«0800» 

PROGRAM X'2000» 
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Table 6. File Control 



Page of SH20-1047-4 
Revised April 11, 1973 
By TNL SN20-9012 



TRACE| 

ID |REGISTER 



14 



TYPE | | 

OF | | 

REQ| TRANSACTION ID | FIELD A 



FIELD B 



X'F5' 



REQUEST CODE FROM 
TCAFCTR OR TCAFCRC 



X'80 
X'84 
X'40 
X«44 
X'20 
X'28 
XMO 

X'CO 
X'EO 
X'FO 
X' AO 
X'BO 
X'A4 



(GET) 

(GET W/UPDATE) 

(PUT) 

(PUT W/NEWREC) 

(GETAREA) 

(GETAREA W/INITIMG) 



(RELEASE 
or ESETL) 



(OPEN) 

(CLOSE) 

(LOCATE) 

(SETL) 

(GETNEXT) 

(RESETL) 



Data set name from TCSFCDI 
fill fields A and B 
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PageofSH20-1047-4 
Revised April 11, 1973 
ByTNLSN20-9012 

Table 7. Transient Data Control 



TRACE 
ID 



REGISTER 



| TYPE | | 

I OF | | 

14 | REQ| TRANSACTION ID | 



FIELD A 



FIELD B 



X'F6' 



REQUEST CODE FROM 
TCATDTR OR TCATDRC 

X'80' (GET) 

X'40' (PUT) 

X'20' (FEOV) 

X'10' (LOCATE) 

X'04' (PURGE) 

X'88' (GET) 

X'48' (PUT) 



Not used 

Data address 
from TCATDAA 

Not used 

Not used 



Not used 

Destination ID 
from TCATDDI 

Not used 

Not used 



Issued by the Asynchronous 
Transaction Control program 
(DFHATP) 



Table 8. Temporary Storage Control 



| | |TYPE| | 

| TRACE | I OF | | 

| ID IREGISTER 1U| REQ| TRANSACTION ID | 



FIELD A 



FIELD B 



X'F7' 



REQUEST CODE FROM 
TCATSTR OR TCATSRC 

X'80' (GET) 

X'90' (GET ADDRESS SUPPLIED) 

X'40« (PUT) 



Data identification 
from TCATSDI 



X'48 1 (PUT IN MAIN) 
X^O 1 (RELEASE) 
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Table 9. Trace Control 



|TRACE| 

| ID f REGISTER 



|TYPE| \ 

I OF | | 

1U| REQJ TRANSACTION ID | FIELD A 



FIELD B 



X'FD' 



REDDEST CODE 
Not used 



XipTJi (Trace turn on) 
X'FF' (Trace turn off) 



Number of repeated entries 
(packed decimal) in Trace 
Table 

Site Cont ents Byte Contents 



CSATRMF1 
CSATRMF2 
TCATRMF 
RESERVED 



TCATRTR 
Reserved 
Reserved 
Reserved 



Table 10. System Termination 



1 | | TYPE! 

ITRACEJ I OF | 

1 TD | REGISTER 14 | REQ| TRANSACTION ID 



FIELD A 



| FIELD B | 



X«EF» 



BI22JST CODE 
Not used 



Not used 



Not used 
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Table 11. CICS-DL/I Interface 



t I 

| TRACE| 

! ID | REGISTER 14 

i 



I TYPE | | 

I OF | J 

| REQ ( TRANSACTION ID | FIELD A 



I 



I 



| FIELD B | 



X'F8» 



REOUEST CODE 
from TCAFCTR 



CALL type 

from 

TCADLLAN 



PCB address 



from TCADLPCB 



Bit Off - DFHFC 

On .- CALL or CALLDLI 

Bits 1-2 00 - Assembler language 
01 - ANS COBOL 
10 - PL/T 

Bits 3-6 Not used 

Bit 7 On - Storage was acquired to build 
CALLDLI parameter list or SSA list 
in DFHFC macro instruction 
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APPENDIX A: EXECUTABLE CICS PROGRAM EXAMPLES 



This section contains an executable application program that performs 
a limited message switching function; that is, data collection, message 
entry, and message retrieval. The source coding is written in Assembler 
language, ANS COBOL, and PL/I. 

*********************************************************************** 

ASSEMBLER EXAMPLE PROBLEM 

*********************************************************************** 

* TITLE »CICS MESSAGE SWITCHING PROGRAM EXAMPLE' * 
DEHCOVER 

****** ****************** ****** 4* ******************************** ******* 

**** APPLICATION PROGRAM **** 

*********************************************************************** 

* * * DUHHY SECTIONS *** 
*********************************************************************** 

COPY COMMON SYSTEM AREA DSECT 
LISTING CONTROL CARD - EJECT 
COPY TASK CONTROL AREA DSECT 
TEMPORARY STORAGE RECORD LENGTH 

DESTINATION IDENTIFICATION 
RETRIEVE ALL INDICATOR 
QUEUE EMPTY MESSAGE CONTROL IND 
LISTING CONTROL CARD - EJECT 
TERM CONT TABLE TERM ENT ADR RG 
COPY TERM CONT TABLE TERM ENTRY 
TERM I/O AREA BASE ADDR REG 
COPY TERMINAL I/O AREA DSECT 
DATA AREA 

TRANSACTION IDENTIFICATION 
DELIMITER 

RESUME REQUEST IDENTIFICATION 
RETRIEVE ALL INDICATOR 1 
DESTINATION IDENTIFICATION 
SUSPEND STORAGE FACILITY IDENT 
DELIMITER 

TERMINAL MESSAGE BEGINNING ADDR 
RETRIEVE ALL INDICATOR 2 
*********************************************************************** 

SPACE 8 LISTING CONTROL CARD - SPACE 8 

TDIABAR EQU 9 TRANS DATA IN AREA BASE ADDR RG 

COPY DFHTDIA COPY TRANS DATA INPUT AREA 

EJECT LISTING CONTROL CARD - EJECT 

*********************************************************************** 

**** APPLICATION PROGRAM **** 

*********************************************************************** 

CTCSATP CSECT CONTROL SECTION - APPL TEST PGM 

USING *,3 USING REGISTER 3 AT * 

LR 03,1U LOAD PROGRAM BASE REGISTER 

B ATPIPIN GO TO INIT PROG INSTR ENTRY 

*********************************************************************** 

EJECT LISTING CONTROL CARD - EJECT 

*********************************************************************** 

* * * D E C L A R ATIVES *** 
*********************************************************************** 

MCPDIEM DC Y(MCPDEML-U) TERMINAL MESSAGE LENGTH 

DC Y(0) 
DC X'15« NEW LINE SYMBOL CONSTANT 





COPY 


DFHCSADS 




EJECT 






COPY 


DFHTCADS 


TWATSRL 


DS 


H 




DS 


H 


TWATDDI 


DS 


CL4 


TWAREAI 


DS 


cm 


TWAQEMCT 


DS 
EJECT 


c 


TCTTEAR 


EQU 


11 




COPY 


DFHTCTTE 


TIOABAR 


EQU 


10 




COPY 


DFHTIOA 


TIOADATA 


DS 


0CL30 


TTOATID 


DS 


CL4 




DS 


C 


TIOARRI 


DS 


0CL6 


TTOARAI1 


DS 


0CL3 


TTOADTD 


DS 


CL4 


TIOASSF 


DS 


OCLU 




DS 


C 


TIOAMBA 


DS 


oc 


TTOARAI2 


DS 


CL3 
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MCPDEML 



DC 08X'17» HARD COPY TERM IDLE CHARACTERS 

DC C» DESTINATION IDENTIFICATION ERROR - PLEASE RESUBMIT 1 

DC X'15' NEW LINE SYMBOL CONSTANT 

ECU *-MCPDIEM TERMINAL MESSAGE TOTAL LENGTH 



DCPDCAML 


DC 




DC 


tCPDCAMD 


DC 


DCPEODML 


DC 




DC 


DCPEODMD 


DC 


DCPEOVML 


DC 




DC 


DCPEOVMD 


DC 


DCPSRAM 


DC 




DC 




DC 




DC 




DC 




DC 


DCPSRAL 


EQD 


DCPRRAM 


DC 




DC 




DC 




DC 




DC 




DC 




DC 


DCPRRAL 


EQD 



*********************************************** *************** ********* 
*********************************************************************** 

* DATACOLLECTION * 
*********************************************************************** 

Y(L'DCPDCAMD) DATA COLL ACKNOWLEDGEMENT LEN 

H'O' 

C DATA COLLECTION HAS BEEN REQUESTED AND IS ABOUT TO BE* 
GIN « DATA COLLECTION ACKNOWLEDGEMENT 

Y(L' DCPEODMD) END OF DATA MESSAGE LENGTH 

H'O' 

C THE DATA HAS BEEN RECEIVED AND DISPATCHED TO THE DESI* 
GNATED DESTINATION » END OF DATA MESSAGE 
Y(L f DCPEOVMD) 
H'O* 

C END OF VOLUME REQUEST HAS BEEN RECEIVED • 
Y(DCPSRAL-4) TERMINAL MESSAGE LENGTH 

Y(0) 

XM5' NEW LINE SYMBOL CONSTANT 

08XM7' HARD COPY TERM IDLE CHARACTERS 

C'DATA COLLECTION SUSPENSION HAS BEEN REQUESTED' 
X»15' NEW LINE SYMBOL CONSTANT 

♦-DCPSRAM TERMINAL MESSAGE TOTAL LENGTH 

Y(DCPRRAL-4) TERMINAL MESSAGE LENGTH 

Y(0) 

X'15» NEW LINE SYMBOL CONSTANT 

08XM7' HARD COPY TERM IDLE CHARACTERS 

C'DATA COLLECTION RESUMPTION HAS BEEN REQUESTED AND IS • 
C'ABOUT TO BEGIN 1 

X»15' NEW LINE SYMBOL CONSTANT 

♦-DCPRRAM TERMINAL MESSAGE TOTAL LENGTH 

*********************************************************************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

*********************************************************************** 

* MESSAGEENTRY * 
*********************************************************************** 

MEPMEAML DC Y (L ' MEPMEAMD) M SG ENTRY ACKNOWLEDGEMENT LNGTH 

DC H'O' 

MEPMEAMD DC C YOUR MESSAGE HAS BEEN RECEIVED AND DISPATCHED TO THE * 

DESIGNATED DESTINATION • MESSAGE ENTRY ACKNOWLEDGEMENT 
*********************************************************************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

*********************************************************************** 

* MESSAGERETRIEVAL * 
*********************************************************************** 

Y(MRPNMML-4) TERMINAL MESSAGE LENGTH 

Y(0) 

XM5V 

08X' 17' 

C THERE ARE NO MORE • 

C MESSAGES QUEUED FOR THIS DESTINATION' 

X'15' NEW LINE SYMBOL CONSTANT 

♦-MRPNPMM TERMINAL MESSAGE TOTAL LENGTH 

Y(MRPNQML-4) TERMINAL MESSAGE LENGTH 

Y(0) 

X»15» NEW LINE SYMBOL CONSTANT 

08X'17» HARD COPY TERM IDLE CHARACTERS 

C'THERE ARE NO MESSAGES QUEUED FOR THIS DESTINATION' 

X'15« NEW LINE SYMBOL CONSTANT 

♦-MRPNMQM TERMINAL MESSAGE TOTAL LENGTH 

*********************************************************************** 

EJECT LISTING CONTROL CARD - EJECT 



MRPNMMM 


DC 




DC 




DC 




DC 




DC 




EC 




DC 


KRPNMML 


EQU 


MRPNMQM 


DC 




DC 




DC 




DC 




DC 




DC 


MRPNQML 


EQU 



NEW LINE SYMBOL CONSTANT 

HARD COPY TERM IDLE CHARACTERS 
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*********************************************************************** 

* * * IMPERATIVES * * * 
* ************ ***************** ** ********************* ** **************** 

* * * * 
*********************************************************************** 

DS OD STORAGE ALIGNMENT - DOUBLE WORD 

DC CL32»MESSAGE CONTROL PROGRAM' 
ATPTPTN DS OD 
L 
L 
CLC 



TCTTEAR,TCAFCAAA 

TIOABAR,TCTTEDA 

=C»CSDC»,TIOATID 

BE ALPDCPN 

CLC =C«CSME» r TTOATID 

BE ALPMEPN 

CLC =C'CSMR»,TIOATID 

BE ALPMRPN 

DFHPC TYPE=ABEND, 
ABCODE=AAPT 

EJECT 



INITIAL PROGRAM INSTRUCTION ENT 

LOAD TERM CONT AREA ADDR REG 

LOAD TERM I/O AREA ADDR REG 

COMPARE TRANSACTION IDENT 

GO TO DATA COLLECTION PROG IF = 

COMPARE TRANSACTION IDENT 

GO TO MESSAGE ENTRY PROG IE = 

COMPARE TRANSACTION IDENT 

GO TO MESSAGE RETRIEVAL PROG 

DFHPC - TYPE = ABEND ' 

DFHPC - ABCODE = AAPT 

LISTING CONTROL CARD - EJECT 



*********************************************************************** 

** APPLICATION LOGIC ** 

*********************************************************************** 

** DATACOLLECTION ** 

*********************************************************************** 

DC CL32»DATA COLLECTION PROGRAM 1 
*********************************************************************** 



ALPDCPN 



DS 

CLC 

BNE 

MVC 

MVC 

MVC 



OH DATA COLLECTION PROGRAM ENTRY 

^■RESUME' ,TIOARRI COMPARE FOR RESUME REQUEST 

DCPBRBN GO TO RESUME REQUEST BYPASS 

TIOATDL(DCPRRAL) ,DCPRRAM MOVE' TERMINAL MESSAGE TO OUTPUT 



DCPFEOV 



TCATSDI (4) ,=C'CSDC« 
TCATSDI + U (U) ,TCTTETI 

DFHTS TYPE=GET f 

TSDADDR=TWATSRL, 

NORESP=DCPRRNR r 

RELEASE=YES 

DFHPC TYPE=ABEND, 
ABCODE=ADCR 

EQU * 



MOVE TEMP STRG DATA IDENT 

MOVE TEMP STRG DATA IDENT 

DFHTS - TYPE = GET * 

DFHTS - T S DATA ADDP = TWATSRL* 

DFHTS - NORMAL RESP = DCPRRNR * 

DFHTS - RELEASE = YES 

DFHPC - TYPE = ABEND * 

DFHPC - ABCODE = ADCR 

FORCED END OF VOLUME ROUTINE 

ISSUE TRANSIENT DATA MACRO 



DFHTD TYPE=FEOV 

MVC TIOATDL( (U+L • DCPEOVMD) ) ,DCPEOVML 

DFHTC TYPE= (WRITE) 

B RETURN 
*********************************************************************** 

DCPRRBN EQU * RESUME REQUEST BYPASS ENTRY 

MVC TWATDDI r TIOADID MOVE DESTINATION IDENTIFICATION 

MVC TCATDDI,TWATDDI 

CLC TIOAMBA(U) r = C»FEOV CHECK FOR FORCED END OF VOL REQ 

BE DCPFEOV BRANCH TO END OF VOLUME ROUTINE 

MVC TIOATDL( (4+L«DCPPC AMD) ) r DCPDCAML 

DCPRRNR EQU * RESUME REQUEST NORMAL RESPONSE 

DFHTC TYPE= (WRITE) DFHTC - TYPE = WRITE 

DFHTC TYPE=(READ) DFHTC - TYPE = READ 

*********************************************************************** 

LISTING CONTROL CARD - SPACE 4 
TERMINAL EVENT WAIT ENTRY 
DFHTC - TYPE = WAIT 
LOAD TERM I/O AREA ADDR REG 

GO TO DUMP TRANSACTION STORAGE 
COMP DATA FOR EOD INDICATION 
GO TO EXIT IF EQUAL 
COMPARE FOR SUSPEND REQUEST 
GO TO SUSPEND REQUEST BYPASS 
MOVE TEMP STRG RECORD LENGTH 



SPACE 


U 


ICPTEWN DS 


OH 


DFHTC 


TYPE=(WAIT) 


L 


TIOABAR,TCTTEDA 


CLC 


=C l DUMP» r TIOATID 


BE 


DCPDPTS 


CLC 


=C'EOD«,TIOADBA 


BE 


DCPEXIT 


CLC 


=C SUSPEND* ,TIOADBA 


BNE 


DCPSRBN 


MVC 


TWATSRL, =H«32» 
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DCPSRMB 



ECPSRAB 



DCPSRNR 



DCPSRBN 



MOVE TEMP STRG DATA IDENT 
MOVE TEMP STRG DATA IDENT 

GO TO MAIN STRG FACILITY BYPASS 
DFHTS - TYPE = PUT * 

DFHTS - T S DATA ADDR = TWATSRL* 
DFHTS = STOR FAC = MAIN 
GO TO ADX STRG FACILITY BYPASS 
MAIN STORAGE FACILITY BYPASS 
DFHTS - TYPE = PUT * 

DFHTS - T S DATA ADDR = TWATSRL* 
DFHTS - STOR FAC = AUXILIARY 
AUX STORAGE FACILITY BYPASS 
DFHTS - TYPE = CHECK * 

DFHTS - NORMAL RESP = DCPSRNR 
DFHPC - TYPE = ABEND * 

DFHPC - ABCODE = ADCS 
SUSPEND REQUEST NORMAL RESPONSE 



MVC TCATSDI(4) ,=C'CSDC' 
MVC TCATSDI+4 (4) , TCTTETI 
CLC =C»MAIN»,TIOASSF 
BNE DCPSRMB 
DFHTS TYPE=PUT, 

TSDADDR=TWATSRL, 

STORFAC=MATN 
B DCPSRAB 
EQU * 
DFHTS TYPE=PUT, 

TSDADDR=TWATSRL, 

STORFAC= AUXILIARY 
EQU * 
DFHTS TYPE=CHECK r 

NORESP=DCPSRNR 
D^HPC TYPE=ABEND, 

ABCODE=ADCS 
EQU * 
MVC TIOATDL(DCPSRAL) ,DCPSRAH MOVE TERMINAL MESSAGE TO OUTPUT 



DFHTC TYPE= (WRITE) 
B RETURN 
EQU * 

MVC TCATDDI r TWATDDI 
XC TCTTEDA,TCTTEDA 
DFHTC TYPE=(READ) 
LH 14,TIOATDL 
LA 14,4(0,14) 
STH 14 r TIOATDL 
DFHTD TYPE=PUT, 

TDADDR=TIOATDL r 
NORESP=DCPNRCN, 
IDERROR=DCPDIEN 
DFHPC TYPE=ABEND, 
ABCODE=ADCP 



DFHTC - TYPE = WRITE 

GO TO RETURN ENTRY 

SUSPEND REQUEST BYPASS ENTRY 

MOVE DESTINATION IDENTIFICATION 

RESET TERMINAL DATA ADDRESS 

DFHTC - TYPE = READ 

LOAD TERMINAL DATA LENGTH 

INCREMENT TERMINAL DATA LENGTH 

STORE TERMINAL DATA LENGTH 

TYPE OF REQ - PUT TRANS DATA * 

TRANSIENT DATA ADDRESS * 

NORMAL RESP CODE ENTRY ADDRESS * 

DESTINATION IDENT ERROR ENTRY 

DFHPC - TYPE = ABEND * 

DFHPC - ABCODE = ADCP 



*********************************************************************** 

DCPNRCN DS OH NORMAL RESP CODE ENTRY ADDRESS 

ST TIOABAR,TCASCSA STORE TERM I/O AREA ADDRESS 

DFHSC TYPE=FREEMAIN DFHSC - TYPE = FREEMAIN 

B DCPTEWN GO TO TEEM EVENT WAIT ENTRY 

*********************************************************************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

***************** ************ ***************** ************************* 

DCPDPTS EQU * DUMP TRANSACTION STOR ROUTINE 

DFHDC TYPE=TRANSACTION,DMPCODE=TRAN 

XC TCTTEDA,TCTTEDA CLEAR TERMINAL DATA AREA ADDR 

DFHTC TYPE=(READ) 

B DCPNRCN RETURN TO MAINSTREAM LOGIC 

*********************************************************************** 

SPACE 4 
*********************************************************************** 

ECPEXIT EQU * EXIT 

MVC TIOATDL ( (4+L'DCPEODMD) ) ,DCPEODML 

DFHTC TYPE= (WRITE) DFHTC - TYPE = WRITE 

B RETURN GO TO RETURN ENTRY 

*********************************************************************** 

EJECT LISTING CONTROL CARD - EJECT 

*********************************************************************** 

* MESSAGEENTRY * 

4********************************************************************** 

DC CL32» MESSAGE ENTRY PROGRAM' 
*********************************************************************** 

ALPMEPN DS OH MESSAGE ENTRY PROGRAM ENTRY 

MVC TCATDDI,TTOADlD MOVE DESTINATION IDENTIFICATION 

MVC TIOATID, TCTTETI MOVE SOURCE IDENTIFICATION 

LH 14,TIOATDL LOAD TERMINAL DATA LENGTH 
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LA 14,4(0,14) 

STH 14 r TIOATDL 

DFHTD TYPE=PUT, 

TDADDR=TTOATDL, 
NORESP=MEPNRCN, 
IDERROR=MEPDIEN 

DFHPC TYPE=ABEND, 
ABCODE=AMEP 



INCREMENT TERMINAL DATA LENGTH 
STORE TERMINAL DATA LENGTH 
TYPE OF REQ - PUT TRANS DATA 
TRANSIENT DATA ADDRESS 
NORMAL RESP CODE ENTRY ADDRESS 
DESTINATION IDENT ERROR ENTRY 
TYPE OE REQ - ABEND PROG CONT 
ABNORMAL TERMINATION CODE 



ALPMRPN 


DS 


OH 




MVC 


TWAREAI,TT0ARAI2 




MVC 


TWATDDT,TCTTETI 




CLC 


=C« ALL»,TIOARAI1 




BNE 


MRPAI1B 




MVC 


TWAREAI,TIOARAI1 




B 


MRPDEBN 


MRPAI1B 


DS 


OH 




CLC 


=CL4' »,TIOADID 




BE 


MRPDEBN 




MVC 


TWATDDI,TTOADTD 


MRPDEBN 


DS 


OH 



*********************************************************************** 

MEPNRCN DS OH NORMAL RESP CODE ENTRY ADDRESS 

MVC TIOATDL((4+L'MEPMEAMD)) ,MEPHEAML 

DFHTC TYPE= (WRITE) DFHTC - TYPE = WRITE 

B RETURN GO TO RETURN ENTRY 

* *** * **** * ** ** **************** *** **************************** ********** 

EJECT LISTING CONTROL CARD EJECT 

*********************************************************************** 

* MESSAGERETRIEVAL * 

*********************************************************************** 

DC CL32* MESSAGE RETRIEVAL PROGRAM' 
*********************************************************************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

*********************************************************************** 

MESSAGE RETRIEVAL PROGRAM ENTRY 
MOVE RETRIEVE ALL INDICATOR 
MOVE DESTINATION IDENTIFICATION 
COMPARE ALL INDICATOR FOR ALL 

MOVE RETRIEVE ALL INDICATOR 

ALL INDICATOR 1 BYPASS 
COMPARE DEST IDENT TO BLANKS 
GO TO DEST ID = BL IF EQUAL 
MOVE DESTINATION IDENTIFICATION 
DESTINATION IDENT EQUALS BLANKS 
************************************************************* ********** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

*********************************************************************** 

MRPGTDN DS OH GET TRANSIENT DATA ENTRY 

MVC TCATDDI,TWATDDT MOVE DESTINATION IDENTIFICATION 

DFHTD TYPE=GET, DFHTD - TYPE = GET DATA * 

NOBESP=MRPNRCN, NORMAL RESP CODE ENTRY ADDRESS * 

QUEZEBO=MRPQERN, DESTINATION QUEUE EMPTY ENTRY * 

IDERROR=MRPDIEN DESTINATION IDENT ERROR ENTRY 

DFHPC TYPE=ABEND, TYPE OF REQ - ABEND PROG CONT * 

ABCODE=AMRP ABNORMAL TERMINATION CODE 

*********************************************************************** 

SPACE 2 LISTING CONTROL CARD - SPACE 2 

*********************************************************************** 

NORMAL RESP CODE ENTRY ADDRESS 
LOAD TRANS DATA AREA ADDRESS 
DFHTC - TYPE = WAIT 
MOVE DATA LENGTH TO MOVE INSTR 
MOVE TRANS DATA TO TERM AREA 
LOAD TERMINAL DATA LENGTH 
SUBTRACT 4 FROM LENGTH 
STORE TERMINAL DATA LENGTH 
DFHTC - TYPE = WRITE * 

DFHTCT - SERV REQ = SAVE AREA 
COMPARE RETRIEVE ALL IND TO ALL 
GO TO RETURN ENTRY IF NOT EQUAL 
MOVE MESSAGE CONTROL INDICATOR 
GO TO GET TRANSIENT DATA ENTRY 



MRPNBCN 


DS 


OH 




I 


TDIABAR,TCATDAA 




DFHTC 


TYPE= (WATT) 




MVC 


MRPMTDI+1 ( 1) ,TDIAIRL+ 1 


MRPMTDT 


MVC 


TIOATDL(O) r TDIAIRL 




LH 


14,TIOATDL 




SH 


14 r =H«4» 




STH 


14,TIOATDL 




DFHTC 


TYPE= (WRITE, 
SAVE) 




CLC 


=CL3'ALL* r TWAREAI 




BNE 


RETURN 




MVI 


TWAQEMCI,X«FF' 




B 


MRPGTDN 
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MRPQERN 


DS 




CLI 




BE 




MVC 




B 


MRPNMQMB 


DS 



************************ ***************************** ****************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

OH DESTINATION QUEUE EMPTY ENTRY 

TWAQEMCI,X»FF' COMPARE MESSAGE CONTROL IND 

MRPNMQMB GO TO NO MSG QUEUED MSG BYPASS 

TIOATDL (MRPNQML) , MRPNMQM MOVE TERMINAL MESSAGE TO OUTPUT 

MRPWRCS GO TO WRITE & RETURN TO C S 

OH NO MESSAGES QUEUED MSG BYPASS 

DFHTC TYPE=(WAIT) DFHTC - TYPE = WAIT 

MVC TIOATDI (MRPNMML) ,MRPNMMM MOVE NO MORE MESSAGE TO T A 
*********************************************************************** 

MRPWRCS DS OH WRITE AND RETURN TO CONT SYS 

DFHTC TYPE= (WRITE) DFHTC - TYPE = WRITE 

B RETURN GO TO RETURN ENTRY 

****************************** ***************** ************************ 

EJECT LISTING CONTROL CARD - EJECT 

******************************************* * ********************* ****** 

* * * * 

DESTINATION IDENT ERROR ENTRY 

STORE TERM I/O AREA ADDRESS 

DESTINATION IDENT ERROR ENTRY 

DESTINATION IDENT ERROR ENTRY 

TIOATDL (MCPDEMI) , MCPDIEM MOVE TERMINAL MESSAGE TO OUTPUT 

DFHTC TYPE= (WRITS) DFHTC - TYPE = WRITE 

*********************************************************************** 

SPACE 4 LISTING CONTROL CARD - SPACE 4 

RETURN DS OH RETURN TO CONTROL SYSTEM 

DFHPC TYPE=RETURN DFHPC - TYPE = RETURN 

*********************************************************************** 

LTORG * LITERAL ORIGIN AT * 

*********************************************************************** 

END CICSATP END OF ASSEMBLY - APPL TEST PGM 



DCPDIFN 


DS 


OH 




ST 


TIOABAR,TCTTEDA 


MEPDTEN 


DS 


OH 


MRPDIEN 


DS 


OH 




MVC 


TIOATDL (MCPDEMI 
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*********************************************************************** 
COBOL EXAMPLE PROBLEM 

***************** ************* ******* ********************************** 

DFHCOVER 

IDENTIFICATION DIVISION. 

PRCGSAM-ID. 

«CICSATP» . 
ENVIRONMENT DIVISION. 
DATA DIVISION. 
WORKING-STORAGE SECTION. 
01 MESSG1. 

02 MCPDIEM PICTURE 99 OSAGE IS COMPUTATIONAL VALUE IS 60. 
02 FILL1 PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS ZERO. 
02 MESSAGE!. 

03 FILL2 PICTURE X VALUE IS • ' . 

03 FTLL3 PICTURE X(8) VALUE IS ALL » '. 

03 FILLU PICTURE X (50) VALUE IS 

•DESTINATION IDENTIFICATION ERROR - PLEASE RESUBMIT*. 
03 FILL5 PICTURE X VALUE IS • •. 
01 MCPDEML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 64. 
01 DCPDCAML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 58. 
01 DCPDCAMD PICTURE X (58) VALUE IS 

• DATA COLLECTION HAS BEEN REQUESTED AND IS ABOUT TO BEGIN •. 
01 DCPEODML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 73. 
01 DCPEODMD PICTURE X (74) VALUE IS ' THE DATA HAS BEEN RECEIVED 

•AND DISPATCHED TO THE DESIGNATED DESTINATION •. 
01 MEPMEAML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 77. 
01 MEPMEAMD PICTURE X (77) VALUE IS 'YOUR MESSAGE HAS BEEN RECEIV 

•ED AND DISPATCHED TO THE DESIGNATED DESTINATION «. 
01 MESSG2. 

02 MRPNMMM PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 64. 
02 FILL11 PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS ZERO. 
02 MESSAGE2. 

03 FILL21 PICTURE X VALUE IS • ' . 
03 FILL31 PICTURE X(8) VALUE IS ALL • «. 

03 FILL41 PICTURE X(54) VALUE IS » THERE ARE NO MORE MESSAG 
»ES QUEUED FOR THIS DESTINATION*. 
03 FILL51 PICTURE X VALUE IS • •. 
01 MRPNMML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 68. 
01 MESSG3. 

02 MRPNMQM PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 59. 
02 FILL12 PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS ZERO. 
02 MESSAGE3. 

03 FILL22 PICTURE X VALUE IS • ' . 

03 FILL32 PICTURE X(8) VALUE IS ALL • •. 

03 FILL42 PICTURE X(49) VALUE IS 

•THERE ARE NO MESSAGES QUEUED FOR THIS DESTINATION 1 . 
03 FILL52 PICTURE X VALUE IS • ». 

1 MRPNQML PICTURE 99 USAGE IS COMPUTATIONAL VALUE IS 63. 
LINKAGE SECTION. 

01 DFHBLLDS COPY DFHBLLDS. 

-02 - TCTTEAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 
02 TIOABAR PICTURE S9 (8) USAGE IS COMPUTATIONAL. 
02 TDIABAE PICTURE S9 (8) USAGE IS COMPUTATIONAL. 
,--0 1 DFHCSADS COPY DFHCSADS. 
„01 DFHTCADS COPY DFHTCADS. 

,02 TWATDDI PICTURE X (4) . 
02 TWAREAI PICTURE X (4) . 

02 TWAQEMCI PICTURE S9 USAGE IS COMPUTATIONAL. 
01 DFHTCTTE COPY DFHTCTTE. 
^01 DFHTIOA COPY DFHTIOA. 
r02 TIOADATA, 

-03 FILLER PICTURE X (80) . 

02 FILLER REDEFINES TIOADATA. 
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03 EODTEST PICTURE X(3). 
02 FILLER REDEFINES TIOADATA. 
03 TIOATID PICTURE X (4) . 
03 FILLER PICTURE X. 
03 TIOADID. 

04 FILLER PICTURE X (4) . 
03 FILLER REDEFINES TIOADID. 

04 TIOARAI1 PICTURE X (3) . 
03 FILLER PICTURE X. 
03 TTOARAI2. 

04 FILLER PICTURE X (3) . 
03 FILLER REDEFINES TIOARAI2. 
04 TIOAMBA PICTURE X. 
1 DFHTDIA COPY DFHTDIA. 

02 TDIADBA PICTURE X (80) . 
PROCEDURE DIVISION. 
ATPIPIN. 

-MOVE CSACDTA TO TCACBAR. 
-MOVE TCAFCAAA TO TCTTEAR. 
^MOVE TCTTEDA TO TIOABAR. 

IF TIOATID = *BSDC» GO TO ALPDCPN. 
IF TIOATID = • BSME* GO TO ALPMEPN. 
IF TIOATID = »BSMR» GO TO ALPMRPN. 
DFHPC TYPE=ABEND, * 

ABCODE=AAPT 
NOTE DATA COLLECTION PROGRAM ***. 
ALPDCPN. MOVE TIOADID TO THATDDI. 
MOVE DCPDCAML TO TIOATDL. 
MOVE DCPDCAMD TO TIOADATA. 
DFHTC TYPE=(WRITE,READ,WAIT) 
DCPTFWN. 

MOVE TCTTEDA TO TIOABAR. 
IF EODTEST = 'EOD 1 GO TO DCPEXIT. 
MOVE TWATDDI TO TCATDDI. 
MOVE ZEROES TO TCTTEDA. 
DFHTC TYPE= (READ, WAIT) 

ADD 4 TO TIOATDL. 
DFHTD TYPE=PUT, * 

TDADDR=TIOATDL, * 

NORESP=DCPNRCN, * 

IDEBROR=DCPDIEN 
DFHPC TYPE=ABEND, * 

ABCODE=ADCP 
DCPNRCN. 

MOVE TIOABAR TO TCASCSA. 
DFHSC TYPE=FREEMAIN 
GO TO DCPTEWN. 
DCPEXIT. 

MOVE DCPEODML TO TIOATDL. 
ADD 4 TO TIOATDL. 
MOVE DCPEODMD TO TIOADATA. 
DFHTC TYPE=WRITE 
GO TO RETURN1. 

NOTE MESSAGE ENTRY PROGRAM ***. 
ALPMEPN. 

MOVE TIOADID TO TCATDDI. 
MOVE TCTTETI TO TIOATID. 
ADD 4 TO TIOATDL. 
DFHTD TYPE=PUT, * 

TDADDR=TIOATDL, * 

NORESP=MEPNRCN, * 

IDERROR=MEPDIEN 
DFHPC TYPE=ABEND, * 

AECODE=AMEP 
MEPNRCN. 
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HOVE MEPMEAML TO TIOATDL. 
ADD 4 TO TIOATDL. 
HOVE MEPMEAMD TO TIOADATA. 
DFHTC TYPE-WRITE 
GO TO RETURN 1. 

NOTE MESSAGE RETRIEVAL PROGRAM ***. 
ALPMBBN. 

MOVE TTOABAI2 TO TWAREAI. 
MOVE TCTTETI TO TWATDDI. 

I? TIOARAI1 NOT EQUAL 'ALL 1 GO TO MRPAT1B. 
MOVE TIOABAI11 TO TWABEAI. 
GO TO MBPDEBN. 
MBPAT1B. 

IE TIOADID EQUAL ' « GO TO MBPDEBN. 
MOVE TIOADID TO TWATDDI. 
MBPDEBN. 
MRPGTDN. 

MOVE TWATDDI TO TCATDDI. 
DFHTD TYPE=GET, * 

NOBESP^MRPNRCN, * 

QUEZERO=MBPQERN, * 

IDEBBOB=MBPDIEN 
DFHPC TYPE=ABEND, * 

ABCODE=AMBP 
MBPNBCN. 

MOVE TCATDAA TO TDIABAE. 
MOVE TDIAIRL TO TIOATDL. 
MOVE TDIADBA TO TIOADATA. 
SUBTRACT 4 FBOM TIOATDL. 
D*HTC TYPE= (WRITE, WAIT, SAVE) 

IP TWABEAI NOT EQUAL 'ALL' GO TO BETURN1. 
MOVE 255 TO TWAQEMCI. 
GO TO MBPGTDN. 
MRPQERN. 

IF TWAQEMCI EQUAL 255 GO TO MBPNMQMB. 
MOVE MRPNMQM TO TIOATDL, 
MOVE MESSAGE3 TO TIOADATA. 
GO TO MBPWRCS. 
MBPNMQMB. 

MOVE MEPNMMM TC TIOATDL. 
MOVE MESSAGE2 TO TIOADATA. 
MBPWBCS. 

DFHTC TYPE=WRITE 
GO TO BETUBN1. 
DCPDIEN. 

MOVE TIOABAR TO TCTTEDA. 
MEPDIEN. 
MBPDIEN. 

MOVE MCPDIEM TO TIOATDL. 
MOVE MESSAGE1 TO TIOADATA. 
DFHTC TYPE=WRITE 
RETURN 1. 

DFHPC TYPE= RETURN 
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*********************************************************************** 

PL/I EXAMPLE PROBLEM 
*********************************************************************** 

/* PL/I EXAMPLE PROBLEM */ 

DFHCOVER 
CTCSA^P: PROCEDURE OPTIONS (MAIN, REENTRANT) ; 
^INCLUDE DFHCSADS; 
"^INCLUDE DFHTCADS; 

2 TWATDDI CHAR (4) , 
2 TWAREAI CHAR (4) , 
2 TWAQEMCI BINARY EIXED (8) ; 
^INCLUDE DFHTCTTE; 
95INCLUDE DFHTIOA; 

2 TIOADATA CHAR (80) ; 
DECLARE 1 TIOA1 BASED (TIOABAR) , 
2 FILL! CHAR (12) , 
2 TIOATID CHAR (4) , 
2 FILL2 CHAR (1) , 
2 TIOARAI1 CHAR (3) , 
2 FILL3 CHAR (2) , 
2 TIOAMBA CHAR (1) ; 
DECLARE 1 TIOA2 BASED (TIOABAR) , 
2 FILL1 CHAR (12) , 
2 EODTEST CHAR (3) , 
2 FILL2 CHAR (2) , 
2 TTOADID CHAR (4) , 
2 FILL3 CHAR (1) , 
2 TIOARAI2 CHAR (3) ; 
^INCLUDE DFHTDIA; 

2 TDTADBA CHAR (80) ; 
DECLARE 1 MCPDEML BINARY FIXED (15) INITIAL (60) ; 

DECLARE 1 MCPDIEM CHAR (60) INITIAL (» DESTINATION IDENTIFI 
CATION ERROR - PLEASE RESUBMIT »)? 

DECLARE 1 DCPDCAML BINARY FIXED (15) INITIAL (59) ; 

DECLARE 1 BCPDCAMD CHAR (59) INITIAL (' DATA COLLECTION HAS BEEN RE 
QUESTED AND IS ABOUT TO BEGIN ♦); 

DECLARE 1 DCPEODML BINARY FIXED (15) INITIAL (74); 

DECLARE 1 DCPEODMD CHAR (74) INITIAL (» THE DATA HAS BEEN RECIEVED 
AND DISPATCHED TO THE DESIGNATED DESTINATION ') ; 
DECLARE 1 MEPMEAML BINARY FIXED (15) INITIAL (77) ; 

DECLARE 1 MEPEAMD CHAR (77) INITIAL (' YOUR MESSAGE HAS BEEN RECEIV 
ED AND DISPATCHED TO THE DESIGNATED DESTINATION •) ; 
DECLARE 1 MRPNMML BINARY FIXED (15) INITIAL (64) ; 

DECLARE 1 MRPNMMM CHAR (64) INITIAL (* THERE ARE NO MORE ME 
SSAGES QUEUED FOR THIS DESTINATION »); 
DECLARE 1 MPPNQML BINARY FIXED (15) INITIAL (59) ; 

DECLARE 1 HRENMQN CHAR (59) INITIAL (« THERE ARE NO MESSAGE 
S QUEUED FOR THIS DESTINATION ') ; 
ATPIPIN: TCTTEAR = TCAFCAAA; 
TIOABAR = TCTTEDA; 

IF (TIOATID = »PSDC») THEN GO TO ALPDCPN; 
IF (TIOATID = , PSME») THEN GO TO ALPMEPN; 
IF (TIOATID = *PSMR') THEN GO TO ALPMRPN; 
DFHPC TYPE=ABEND, 
ABCODE=AAPT 
DECLARE 1 CON1 CHAR (32) INITIAL ('DATA COLLECTION PROGRAM 1 ) ; 
ALPDCPN: TWATDDI = TIOADID; 
TIOATDL = DCPDCAML; 
TIOADATA = DCPDCAMD; 
DFHTC TYPE= (WRITE, READ, WAIT) 



DCPTEWN: 



TIOABAR = TCTTEDA; 

IF (EODTEST = «EOD f ) THEN GO TO DCPEXIT; 

TCATDDI = TWATDDI; 
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DNSPEC (TCTTEDA) =0; 
DFHTC TYPF=(READ,WAIT) 

TTOATDL = TIOATDL + 4; 
DFHTD TYPE=PUT, * 

TDADDR=TIOATDL, * 

NORESP=DCPNRCN, * 

TDEBROR=DCPDIEN 
DFHPC TYPE=ABEND, * 

ABCODE=ADCP 
DCPNRCN: TCASCSA = TIOABAR; 
DFHSC TYPE=FREEMAIN 
GO TO DCPTEWN; 
DCPEXIT: TIOATDL = DCPEODML; 
TIOADATA = DCPEODMD; 
DFHTC TYPE=WRITE 
GO TO RETURN; 
DECLARE 1 CON2 CHAR (32) INITIAL ('MESSAGE ENTRY PROGRAM 1 ); 
ALPMEPN: TCATDDI = TIOADID; 
TIOATID = TCTTETI; 
TIOATDL = TIOATDL + 4; 
DEHTD TYPE=PUT, * 

TDADDR=TIOATDL, * 

NOBESP=MEPNRCN, * 

IDERROR=M5PDTEN 
DFHPC TYPE=ABEND r * 

AECODE=AMEP 
MEPNRCN: TIOATDL = MEPMEAML; 
TIOADATA = MEPEAMD; 
DFHTC TYPE=WRITE 
GO TO RETURN; 
DECLARE 1 CON3 CHAR (32) INITIAL ('MESSAGE RETRIEVAL PROGRAM') ; 
ALPMRPN: TWAREAI = TIOARAI2; 
TWATDDT = TCTTETI; 

IF (TIOARAI1 * 'ALL') THEN GO TO MRPAI1B; 
TWAREAI = TIOARAI1; 
GO TO MRPDEBN; 
MRPAT1B: IF (TIOADID = ' *) THEN GO TO MRPDEBN; 

TWATDDI = TIOADID; 
MRPDEBN: MRPGTDN: TCATDDI = TWATDDI; 

DTHTD TYPE=GET, * 

NORESP=MRPNRCN, * 

QUEZERO=MRPQERN, * 

IDERROR=MRPDIEN 
DFHPC TYPE= ABEND, * 

ABCODE=AMRP 
MRPNRCN: TDIABAR = TCATDAA; 

TIOATDL = TDIAIRL - 4; 
TIOADATA = TDIADBA; 
DFHTC TYPE= (WRITE, WAIT, SAVE) 

IF (TWAREAI * 'ALL •) THEN GO TO RETURN; 
TWAQEMCI = •11111111'B; 
GO TO MRPGTDN; 
MRPQERN: IF (TWAQEMCI = ' 1 1 1 1 1 1 1 1 ' B) THEN GO TO MRPNMQMB; 
TIOATDL = MRPHQML; 
TIOADATA = MRPNMON; 
GO TO MRPWRCS; 



MRPNMQMB: 



MRPWRCS 



TIOATDL = MRPNMML; 
TIOADATA = MRPHMMM; 



DFHTC TYPE=WRITE 
GO TO RETURN; 
DCPDIEN: TCTTEDA = TIOABAR; 
MEPDIEN: MRPDIEN: TIOATDL = MCPDEML; 
TIOADATA = MCPDIEM; 
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EBTURN: 



DFHTC TYPE=WRTTE 



END; 
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APPENDIX E: CICS MACRO INSTRUCTIONS 



This section lists the CICS macro instructions used to request 
supervisory and data management services. These macro instructions 
are written in Assembler language and, as all Assembler language 
instructions, are written in the following format: 

N am e Operation Operands Comments 

blank DFHxxxxx One or more operands 

or separated by commas 

symbol 

The name field of a CICS macro instruction must be left blank if 
the macro instruction is used in conjunction with a high-level language 
(ANS COBOL or PL/I) ; if a label is desired for the macro instruction, 
it may be placed on the card preceding the macro instruction. 

The operation field of a CICS macro instruction must begin before 
card column 16 and must contain the three-character combination "DFH" 
in the first three positions of the operation field. Up to five 
additional characters can be appended to DFH to complete the symbolic 
name for the appropriate program or table. Since DFH is reserved for 
CICS macro instrucitons, no other statement may begin with this three- 
character combination. 

The operand field of a CICS macro instruction contains one or more 
operands separated by commas. In this publication, parentheses are 
used to indicate those operands where more than one applicable parameter 
(keyword and otherwise) can be specified with a single use of the 
operand. Where parentheses are not used, only one parameter at a time 
can be specified as part of the operand; a choice must be made in the 
case of more than one applicable parameter. Since a blank character 
indicates the end of the operand field, the operand field must not 
contain blanks except after a comma on a continued card or after the 
last operand of the macro instruction. The first operand on a 
continuation card must begin in column 16. 

When a CICS macro instruction is contained on more than one card, 
each card containing part of the macro instruction (except the last 
card) must contain a character (for example, an asterisk) in column 
72 indicating that the macro instruction has been continued on the 
next card. 

In the following listing of CICS macro instructions, default 
parameters (where applicable) are indicated by an underscore. An 
asterisk in card column 72 indicates that the macro instruction is 
continued on the next card. 



!£SK SERVICES 

DFHKC TYPE=ATTACH, * 

FCADDR=symbolic address, * 

TRANSTD=name 

DFHKC TYPE=CHAP, * 

PRTY=priority value 
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DFHKC TYPE=WAIT, * 

DCI=SING1E,LTST,DISP, * 

ECADDR=symbolic address 

DFHKC TYPE=ENQ,DEQ, * 

QABGaDF=syrabolic address, * 

QARGLNG=number 

DFHKC TYPE=PURGF,NOPURGE 



STORAGE SERVICES 



DFHSC TYPE=GETMAIN f * 

INITIMG=number,YES f * 

NUMBYTE=number, * 

COND=YES or (YES, symbolic address) or * 

(NO, symbolic address) , * 
CLASS=TERMINAL,USER,TRANSDATA,TE?1PSTRG 

DFHSC TYPE=FREEMAIN, * 
PELEASE=ALL 



IBCGRAM SERVICES 



DFHPC TYPE=LINK, * 

PROGFAM=name 

DFHPC TYP3=XCTL, * 

PROGRAM=name 

DFHPC TYPE=LOAD, * 

PROGRAM=name, * 

LOADLST=NO 

DFHPC TYPE=RETORN, * 

TRANSID=transaction code 

DFHPC TYPE=DELETE, * 

PROGRAM=name 

DFHPC TYPE=ABEND, * 

ABCODE= value, YES 



DUMP SERVICES 



DFHDC TYPE=TRANSACTION, * 

DMPCODE=value 

DFHDC TYPE=CICS, * 

DMPCODE=value 

DFHDC TYPE=COMPLETE, * 

DMPCODE=value 

DFHDC TYPE=PARTIAL, * 

LIST=TERMINAI, PROGRAM, SEGMENT, TRANS ACTION, * 

DMFCODE=value 
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'ERHINAL SERVICES 

DFHTC TYPE=(WRITE,HRITEL, READ, READL, WAIT, ERASE, SAVE, OIU, * 

DISCONNECT, BESET, READB, COPY , ERASEAUP, CBUFF, * 

PASSBK,TRANSPARENT,PSEODOBTN,NOTRANSLATE) , * 

LINEADR=number,YES, * 

CTLCHAR=hexaaecimal number, YES, * 

DEST=symbolic name, YES, * 
EOF=symbolic address 

DFHTC TYPE= (GET, PUT, ERASE, SAVE, TRANSPARENT, PSEUDOBIN) , * 

LINEADR=number,YES, * 

CTLCHAR=hexadecimal number, YES , * 

DEST=symbolic name, YES, * 
EOF=symbolic address 

DFHTC TYPE= (PAGE, SAVE) , * 

LINEADR=number,YES, * 

CTLCHAR=hexadecimal number, YES, * 
DEST=symbolic name, YES 

DFHTC TYPE= (CONVERSE, ERASE, SAVE) , * 

LINEADR=number,YES, * 

CTLCHAR=hexadecimal number, YES, * 
DEST=symbolic name, YES 

DFHTC EOF=symbolic address 



FILE SERVICES 

DFHFC TYPE=GET, * 

DATASET=symbolic name, * 

RDIDADR=symbclic address, * 

SEGSET=symbolic name, YES , ALL, * 

INDEX=symbolic name, YES, * 

TYPOPER=UPDATE, * 

RETMETH=RELREC,KEY, * 

NORESP=symbolic address, * 

DSIDER=symbolic address, * 

SEGIDER=symbolic address, * 

NOTFND=symbolic address, * 

INVREQ=symbolic address, * 

TOERROR=symbclic address, * 

DDPDS=symbolic address, * 
NOTOPEN=symbclic address 

DFHFC TYPE=PUT, * 

RDIDADR=symbclic address, * 

SEGSET=YES, * 

TYPOPER=NEWREC, UPDATE, * 

NORESP=symbolic address, * 

DUPREC=symbolic address, * 

INVREQ=symbolic address, * 

IOERROR=symbclic address, * 

NOSPACE=symbclic address, * 
NOTOPEN=symbclic address 
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DFHFC TYPE=GETAREA, * 

BATASET=syrabolic name, * 

INITIMG=value,YES, * 

DSIDER=symbolic address, * 

NORESP=symbolic address, * 

INVREQ=symbolic address, * 
NOT0PEN=symbclic address 

DFHFC TYPE=RELEASE, * 
THVREQ=symbclic address 

DPHFC TYPE=SET1, * 

DATASET=symbolic name, * 

RDIDADR=symbclic address, * 

SEGSET=symbolic name, YES, ALL, * 

RETMETH=RELREC,KEY, * 

NORESP=symbolic address, * 

DSIDER=symbolic address, * 

SEGIDER=symbclic address, * 

INVREQ=symbolic address, * 
NOT0PEN=syrabolic address 

DFHFC TYPE=GETNEXT, * 

SEGSET=symbolic name, YES, ALL, * 

NORESP=symbolic address, * 

SEGIDER=symbclic address, * 

TNVREQ=symbolic address, * 

TOEBBOR=symbclic address, * 

NOTOFEN=symbclic address, * 
ENDFILE=symbolic address 

DFHFC TYPE=ESETL, * 
INVREQ=symbolic address 

DFHFC TYPE=EESETL, * 

SEGSET=symbolic name, YES, ALL, * 

NOSESP=symbclic address, * 
SEGIDER=symbclic address 

DFHFC TYPE=CHECK, * 

NOBESP=symbclic address, * 

DSIDER=symbolic address, * 

SEGIDER=symbclic address, * 

NOTFND=symbolic address, * 

DUPREC=symbolic address, * 

TNVREQ=symbclic address, * 

IOERROR=symbclic address, * 

DUPDS=symbolic address, * 

NOSPACE=symbclic address, * 

NOTOFEN=symbclic address, * 
ENDFTLE=symbolic address 

1SANSTENT £ATA SERVICES 

EFHTD TYPE=PUT, * 

DESTID=symbolic name, * 

TDADDR=symbolic address, * 

NORESP=symbolic address, * 

IDERROR=syrabclic address, * 

TOERROR=symbclic address, * 

NOTOPEN=symbclic address, * 
NOSPACE=symbclic address 
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DFHTD TYPE=GET r * 

DESTID=symbolic name, * 

NORESP=symbclic address, * 

QUEZERO=syrabclic address, * 

IDERROR=symbclic address, * 

IOERROR=symbolic address, * 
NOTOPEN=symbclic address 

DFHTD TYPE=FEOV, * 

DESTID=symbolic name, * 

NOBESP=symbolic address, * 

IDEPEOR=symbclic address, * 
NOTOPEN=symbclic address 

DFHTD TYPE=PORGE, * 

DESTID=symbolic name, * 

IDERROR=symbclic address, * 
NORESP=symbclic address 

DFHTD TYPE=CHECK, * 

NORESP=symbolic address, * 

QDEZERO=symbclic address, * 

IDERROR=symbclic address, * 

IOERROR=symbolic address, * 

NOTOPEN=symbclic address, * 
NOSPACE=symbclic address 

ZZSEOMEL STORAGE SERVICES 

DFHTS TYPE=PUT, * 

DATAID=name, * 

TSDADDR=symbolic address, * 

STORFAC= AUXILIARY, HA IN, * 

NOBESP=symbolic address, * 
INVREQ=symbolic address 

DFHTS TYPE=GET, * 

DATAID=name, * 

TSDADDR=symbclic address, YES, * 

RELEASE=YES,NO, * 

NORESP=symbolic address, * 

IDERROR=symbclic address, * 
IOERROR=symbclic address 

DFHTS TYPE=RELEASE, * 

DATAID=name, * 

NORESP=symbolic address, * 
IDERROR=symbclic address 

DFHTS TYPE=CHECK, * 

NORESP=symbolic address, * 

IDEBROR=symbclic address, * 

IOERROR=symbclic address, * 
INVREQ=symbolic address 

2Z2E SERVICES 

DFHIC TYPE=GETIME, * 

FORM=BINARY, PACKED, * 

TIMADR=symbolic address, YES, * 

NORESP=symbolic address, * 
INVREQ=symbolic address 
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DFHIC TYPE=WAIT, * 

INTRVAL=numeric value, YES, * 

TIHE=numeric value, YES, * 

REQID=name,YES, * 

N0HE5P=symbolic address, * 

INVREQ=symbolic address, * 
EXPIRD=symbolic address 

DFHIC TYPE=POST, * 

INTRVAL=numeric value, YES, * 

TIME=numeric value, YES, * 

REQID=name,YES, * 

NORESP=symbclic address, * 

INVREQ=symbolic address, * 
EXPIRD=symbolic address 

DFHIC TYPE=INITTATE, * 

INTRVAL=nuiQeric value, YES, * 

TIME=numeric value # YES, * 

REQID=name,YES, * 

TRANSID=name, * 

TRMIDNT=name,YES, * 

NORESP=symbclic address, * 

INVREQ=symbolic address, * 

TRNIDER=symbclic address, * 
TRHIDER=symbclic address 

DFHIC TYPE=PUT, * 

INTRVAL=nuraeric value, YES, * 

TIME=numeric value, YES, * 

REQID=name,YES, * 

TRANSID=name, * 

TRMIDNT=name,YES, * 

ICEADDR=symbolic address, YES, * 

NORESP=symbclic address, * 

INVREQ=symbolic address, * 

TRNIDER=symbclic address, * 

TRMIDER=symbolic address, * 
IOERROR=symbclic address 

DFHIC TYPE=GET, * 

ICDADDR=syfflbclic address, YES, * 

NORESP=symbolic address, * 

INVREQ=symbolic address, * 

ENDDATA=symbclic address, * 

NOTFND=symbclic address, * 
IOERROR=symbclic address 

DFHIC TYPE=RETRY, * 

NORESP=symbolic address, * 

IflVREQ=symbclic address, * 

NOTFND=symbolic address, * 
IOERROR=symbolic address 

DFHIC TYPE=CANCEL, * 

REQID=name,YES, * 

NORESP=symbolic address, * 

INVREQ=symbclic address, * 
NOTFND=symbolic address 
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DFHIC TYPE=CHECK, * 

NOBESP=symbolic address, * 

INVREQ=symbolic address, * 

EXPIRD=symbolic address, * 

TRNIDER=symbolic address, * 

TRMIDER=symbclic address, * 

IOERBOR=symbclic address, * 

NOTFND=syrabolic address, * 
ENDDATA=symbolic address 

]L19_GRAM TESTING AND DEBUGGING 

DFHTR TYPE=ON, * 
STYPE=SINGLE,ALL, (system symbol) , SYSTEM, USEE 

DFHTR TYPE=OFF, * 
STYPE=SINGLE,ALL, (system symbol) , SYSTEM, USER 

D'HTR TYPE=ENTEY, * 

STYPE=SYSTEM,USER, * 

ID=number, * 

DATA 1=symbol, (symbol) , * 

EDATA1=register, (register) , * 

DAT A2=symbol, (symbol) , * 

BDATA2=register, (register) , * 

DATA 1TP=HBIN, FEIN, CHAR, PACK, POINTER, * 
D AT A2TP=HBIN,EBIN r CHAR, PACK, POINTER 

3270 OFFLINE MAP BUILDING 

raapname DFHMDI TYPE=DSECT, MAP, FINAL, * 

TEBM=3270, * 

LANG=ASM, COBOL, PL 1, * 

BASE=name, * 

MODE=IN,OUT, * 
CTRL= (PRINT, L40,L64,L80,HONEOM,FREEKB,AL ARM, FSSET) 

name DFHMDF 

LENGTH=number, - * 

POS=number, * 
ATTRB=(ASKIP,PROT,UNPROT,NUM,BRT,DRK,NORM,DET,TC,FSET) , * 

JUSTIFY= (LEFT, RIGHT, BLANK, ZERO) , * 

INITIAL='any user information*, * 
GRPNAME=user group name 

2220. ONLINE MAP INVOCATION 

DFHBMS TYPE= (IN, OUT, ERASE, WAIT, SAVE) , * 

MAP=»map name 1 , YES, * 

DATA=NO, YES, ONLY, * 

CTRL=(PRINT,LU0,L64,L80,HONEOM,FREEKB, ALARM, FRSET) , * 

CURSOR=number,YES, * 
MAPADR=symbolic address, YES 

TATA LANGUAGE/I SERVICES 

DFHFC TYPE=(DL/I,PCB) , * 

PSB=psbname, symbolic name, YES, * 

NORESP=symbclic address, * 
INVREQ=symbolic address 
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DFHFC TYPE= (DL/I,f unction) , * 

PCB=symbolic address, (register) , * 

EBKAREA=symtolic address ,YFS, (register) , * 

SSAS=NO, (ssacount,ssa1 ,ssa2,...) , * 

SSALIST=YES, NO, symbolic address, (register) , * 

NOHESP=symfcolic address, * 

NOT0PEN=syrabolic address, * 
INVREQ=symbolic address 

DFHFC TYPE=(DL/I,T) , * 

NORESP=symbolic address, * 

INVREQ=symbclic address 

CALLDLI ASMTDLI, (parmcount, function , pcb,workarea, 

segment search arguments,...) or 
CBLTDLI, (parmcount, function, pcb,workarea, 
segment search arguments,...) 

(CALLDLI is a special form of the CALL macro instruction for 
DL/I CALL'S in Assembler language programs.) 
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APPENDIX C: CICS DUMP CODES 



When abnormal conditions occur, the message 

TRANSACTION xxxx ABEND xxxx AT xxxx 

is sent to Transient Data destination CSMT, indicating that the 
identified transaction attached to the identified terminal has been 
abnormally terminated. The ABEND (dump) code indicates the origin 
or cause of the error, and may be originated by the user or by CICS. 
Following are the ABEND codes for abnormal terminations initiated by 
CTCS. 



Code 



AACA 



AICA 



Dete ct ing Pr og ram Cause 

Abnormal Condition Invalid error code passed to DFHACP 

in the TCA at location TCAPCABR. 
A complete system dump is provided 
to assist in determining the problem. 



Interval Control 



AKCA 



Task Control 



AKCD 



Task Control 



A runaway task condition has been 
detected and the task is being 
abnormally terminated. The condition 
indicates a possible logical loop 
within the user's program. 

Another CICS task has requested 
Task Control to abnormally terminate 
this task as a result of actions 
initiated by: 

• Terminal Abnormal Condition 
program (DFHTACP) ; the 
appropriate message is found 
at destination CSMT. 

• Task Termination portion of 
the Master Terminal facility. 

The Asynchronous Transaction Control 
program (DFHATP) terminates 
asynchronous tasks when: 

• User requests deletion of a 
batch via CWTR delete option 
while CICS is actively processing 
that batch; DFHATP abnormally 
terminates the task and purges 
all remaining data from the 
queues. 

• An asynchronous task tries to 
read more data than is available; 
DFHATP abnormally terminates 

the task. 

Invalid code in the dispatch control 
indicator field. The invalid code 
can be found in the TCA at symbolic 
location TCATCDC. Valid codes 
(masks) : 

X'10 1 Not dispatchable (not 
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Co^e Detecting Program Cause 



AKCP Task Control 



AKCP Task Control 



applicable to CICS/DOS-ENTRY) 
X'20' Dispatchable 
X'40' Wait on list of events 
X'SO 1 Wait on single event 

A stall condition has been detected 
and this task is being abnormally 
terminated. This task carries a 
code indicating it is purgeable. 

The type of reguest code is invalid. 
The invalid code can be located 
in the TCA at symbolic location 
TCATCTR. Valid codes: 



AKCS 



APCB 



Task Control 



Program Control 



APCC 



APCT 



APCL 



APCP 



APCR 



Program Control 

Program Control 

Program Control 
Program Control 
Program Control 



X»01* 


Enqueue 


X'02» 


Dequeue 


X»0ft« 


System 


X^B 1 


System 


X» 10« 


Task Origination 


X' 11» 


System 


X 1 12« 


System 


X« 1U» 


System 


X'20» 


Priority Change 


X»40« 


Task Wait 


X'80» 


Task Termination 



The reguest exceeds available Subpool 
1 storage. CICS/DOS-ENTRY only. 

An attempt was made to execute a 
PL/T program but the proper support 
was not included in DFHSAP. For 
example, PL/I F level execution 
attempted but support generated 
only for PL/I Optimizing Compiler. 

An attempt was made to execute an 
ANS COBOL program but ANS COBOL 
support was not generated in Program 
Control. 

An attempt was made to execute a 
PL/I program but PL/I support was 
not generated in Program Control. 

There is insufficient main storage 
available for the reguested program. 

An error occurred on the read of 

a requested program from the library. 

Task reguest for service is invalid. 

The invalid code can be located 

in the TCA at TCAPCTR. Valid Codes: 



X'01' 


LINK 


X'02» 


XCTL 


X'04' 


LOAD 


x^os* 


DELETE 


X« 10» 


RETURN 


X»U0» 


ABEND 


X«60» 


ABEND with DUMP 
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Code 



Dete ct ing Program Ca us e 



APCT Program Control 



APIA Program Interrupt 



X*90» RETURN from Task Control pgm 

A task issued a request for a program 
which is not in the PPT. The invalid 
program ID is in the TCA at TCAPCPI. 

A program check has occurred during 
the subject task execution. The 
PSW at the time of interrupt is 
saved in the task's TCA. 



ASCR 



Storage Control 



The request for service is invalid. 
Valid codes: 



ASCT Storage Control 



ATDT Transient Data 



X'20' Released Storage 
X'40' Release Storage 
X'80* Acquire Storage 

The request exceeds available Subpool 
1 storage. CICS/DOS-ENTRY only. 

The type of destination code is 
invalid. The invalid code can be 
located in the DCT at symbolic 
location TDDCTDT. Valid Codes: 



X'20' Indirect 
X'40' Extrapartition 
X'80' Intrapartition 
X'90' Intrapartition with automatic 
transaction initiation 



ATDT 



Transient Data 



Request for service is invalid. 
The invalid code is in the TCA and 
can be located at TCATDTR. Valid 
codes: 



BMIP Basic Mapping 
Support 

BMOP Basic Mapping 
Support 

BMTT Basic Mapping 
Support 



X' 


ou» 


X' 


08' 


X' 


10' 


x« 


20' 


x« 


40' 


X' 


80' 



Purge destination 
Destination entry address 
passed to the Transient Data 
Control program 
Locate Destination Control 
Table (DCT) entry 
Eorced end of volume on 
extrapartition data set 
Output service on 
intrapartition data set 
Input service on 
intrapartition data set 



An input mapping request was issued 
and the map provided was for output. 

An output mapping request was issued 
and the map provided was for input. 

A request was made for 3270 mapping 
support and the device is not a 
3270. 



DLDY 



DL/I Interface 



A DL/I CALL was issued under CICS/OS, 
but the DL/I Interface dummy program 
was loaded at system initialization. 
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C od e Detecting Program Cause 

QUA DL/I Interface An irrecoverable error occurred 

during execution of the CICS-DL/I 
Interface program under CICS/OS. 
The DLTA code is returned to all 
transactions from which DL/I CALL'S 
are subsequently issued. 

DLPA DL/I Interface A DL/I abend (or pseudo abend) 

occurred during transaction 
processing under CICS/OS. The abend 
code is found in the TCA at TCADLECB. 

Svstem Action: In addition to the dump services requested by 
application programs, CICS also requests dumps for abnormal 
conditions and places specific dump codes in the dumps for ready 
identification. 

Action: Analyze the error condition indicated by the abend 
code. 
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APPENDIX D: 3270 MAP GENERATION AND ASSEMBLY ERROR MESSAGES 



This section contains a listing of error messages applicable to 
CICS Basic Mapping Support (BMS) for the 3270 Information Display 
System. The severity of program assembly errors is indicated by codes 
4, 8, 12, and 16; codes 4 and 8 indicate an error condition that might 
not prevent program execution, while codes 12 and 16 indicate an error 
condition so severe that program execution is impossible. 

UFHBMOC0 1 TYPE IS NOT VALID; DSECT ASSUMED 

S ey er ity : 1 2 

M e aning: The DFHMDI TYPE=parameter specification is 

invalid. CICS assumes TYPE=DSECT and continues 
to analyze the map. 

Action; Supply a valid DFHMDI TYPE=parameter 
specification and reassemble. 

DEHBM0002 INVALID LANG OPERAND; ASM IS ASSUMED. 

Seve rit y : 4 

Meaijinjg: The DFHMDI LANG=parameter specification is 

invalid. CICS assumes LANG=ASM and continues 
to analyze the map. 

Action: Supply a valid DFHMDI LANG=parameter 
specification and reassemble. 



DFHBMC003 MODE INVALID; OUT IS ASSUMED 
Severity : 1 2 
Meaning : 



Action: 



The DFHMDI MODE=pararaeter specification is 
invalid. CICS assumes MODE=OUT and continues 
to analyze the map. 

Supply a valid DFHMDI MODE=parameter 
specification and reassemble. 



DFHBM0005 CONFLICTING PRINTER FORMATS; HONEOM ASSUMED 



S ey er i ty : 
Meaning : 

Action: 



The DFHMDI CTRL=parameter specification includes 
more than one of the parameters HONEOM, L40, 
L64, and L80. CICS assumes CTRL=HONEOM. 

Supply required printer format specification 
via the CTRL operand and reassemble, or accept 
the default. 
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DFHBM0006 INVALID CTRL OPERAND IS REJECTED 

Severity: 12 

Weaning: The DFHMDI CTRL=parameter specification is 
invalid. CICS rejects the option specified 
and continues to analyze the map. 

Ac t i on : Check coding of CTRL options against macro 
description and reassemble the map. 

DFHBMC007 ONLY 3270 IS VALID. ASSUMED. 

S ever ity : H 

Meaning: The DFHMDI TERM=parameter specification specifies 
a terminal other than the 3270. CICS assumes 
TERM=3270 and continues to analyze the map. 

Action: TERM=3270 is the only valid specification. 
If omitted, the default is TERM=3270. 

DFHBMC007A MAPNAME IS GT 7 CHARS 
Severity, : 8 

neapin g: The map name is greater than seven characters 
in length. 

Action: Reduce the name to seven characters or less 
and reassemble the map. 

DFHBMC008 FIELD MACRO AFTER DFHMDI TYPE=FINAL DISCARDED 

Severity : 8 

Meaning: The DFHMDF macro instruction was encountered 
after a DFHMDI TYPE=FINAL macro instruction 
and before another DFHMDI TYPE=DSECT macro 
instruction or DFHMDI TYPE=MAP macro instruction; 
CICS ignores the DFHMDF macro instruction. 

Ac tion: Examine macro instructions for correct seguence 
and reassemble map. 

DFHBM0009 NO LENGTH; MACRO DISCARDED 

Se ve r i ty : 8 

Mea nin g: The DFHMDF LENGTH=number specification has been 
omitted. CICS ignores this field macro 
instruction and continues to analyze the map. 

Action: Supply a valid LENGTH value (1-256) for the 
field and reassemble map. 

DFHBM0010 NO POS; MACRO DISCARDED 
Severity: 8 
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M eani ng: The DFHMDF L EN GTH= number specification has been 
omitted. CICS ignores this field macro 
instruction and continues to analyze the map. 

Action: Supply a valid POS value (0-1919) for the field 
and reassemble map. 

DFHBM0011 LENGTH CUT OF RANGE; MACRO DISCARDED 

Severity: 8 

Weaning: The DFHMDF LENGTH=number specification is not 

within the range 1-256. CICS ignores this field 
macro instruction and continues to analyze the 
map. 

Action: Supply a LENGTH value within the range 1-256 
and reassemble map. 

DFHBM0013 POS OUT OF RANGE; MACRO DISCARDED 



S e ver ity : 

Me an ing : 

Action: 



The DFHMDF POS=number specification is less 
than zero or greater than 1919. CICS ignores 
this field macro instruction and continues to 
analyze the map. 

Supply a valid POS value within the range 0- 
19 19 and reassemble map. 



DFHBMOOm FIELD POSITION REQIRES 3270 MODEL 2 

Severity,: 

Meaning: The DFHMDF POS=number specification specifies 
a location that reguires the 1920-character 
3270 (Model 2) . 

Action: Ensure that this map is never used for a 3 270 
Model 1. 



DFHBM0015 OVERLAP flITH PREVIOUS FIELD 



Severity : 
Meaning : 



Action: 



The DFHMDF POS=number specification specifies 
a position that is within the scope of the 
preceding field definition. CICS accepts the 
specified value and continues to analyze the 
map. 

Ensure that the field overlap is acceptable. 
If not, correct by supplying a POS value that 
is at least one greater than the sum of the 
POS and LENGTH values of the previous field 
in the map. As an alternative, change the POS 
or LENGTH values of the previous field and 
reassemble map. 
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DFHBMC0 16 POS 'NOT IN ASCENDING SEQUENCE. MACRO DISCARDED. 

Severity : 8 

Meaning: The DPHMDF POS=number specification is not 
greater than the POS value of the preceding 
field. CICS ignores this field macro instruction 
and continues to analyze the map. 

action; Check the POS values for the two fields and 
the order of the macro instructions and 
reassemble map. 

DFHBM00 17 IRRECOVERABLE ERROR ENCOUNTERED BY DFHMDF 

Severity : 1 6 

M ean ing: An irrecoverable situation was encountered by 
DPHMDF during map analysis. CICS abandons any 
further map analysis. 

Action : Examine the map specification carefully for 
invalid parameters; see that the macro 
instructions are properly ordered. Correct 
any errors and reassemble map. If the error 
persists, contact your IBM representative after 
ensuring the availability of (1) a listing of 
the map analysis with the error messages, and 
(2) the input causing the error message to be 
generated. 

D?HBMC0 18 FIELDNAME MUST BE CODED WITH GROUPNAME PRESENT 

Severity : 8 

Meaning: The DFHMDF macro instruction was coded with 

a group name but the name field was not supplied. 
CICS assigns a null value to the name field 
and continues to analyze the map. 

Action: All fields within a named group require the 

name field to be coded. Supply a unique field 
name and reassemble map. 

DFHBM0019 NO FIELD NAME. MACRO DISCARDED. 

Severity: 4 

Meaninq: The DFHMDF MODE=IN specification encountered 

an entry with no name field entry. CICS ignores 
this field macro instruction and continues to 
analyze the map. 

Action : If a symbolic storage definition entry is 

required for this field, supply a name in the 
name field and reassemble map. Rejection of 
a DFHMDF MODE=TN specification with an empty 
name field may be quite valid if the same map 
generation submitted for output symbolic storage 
definition is used to generate the symbolic 
storage definition for the input from that map. 
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DFHBM0020 DETECTABLE FIELD CANNOT BE CONTAINED UNDER A GROUP NAME 

Severity : 8 

Meaning: DFHMDE ATTRB=DET was specified for a field 
contained witin a group. CICS ignores this 
field macro instruction and continues to analyze 
the map. 

Actio n; Check the specifications of grouped fields 

within the map and the ATTRB specification for 
this field. Reassemble map. 

DEHBM0021 INVALID xxxxxxxx ATTRIBUTE SPECIFIED; IGNORED 

Severity; 4 

Meaning: The DFHMDF ATTRB=parameter specification is 

invalid. CICS ignores the invalid specification 
and continues to analyze the map. 

Action: Check the coding of the ATTRB operand and 
reassemble map. 

DFHBM0022 xxxxxxxx AND xxxxxxxx ARE INCOMPATIBLE; ASKIP ASSUMED 

S ever ity : 8 

Meaning: Conflicting attributes were specified for this 
field in the DFHMDF ATTRB=parameter macro 
instruction. CICS assumes ATTRB=ASKP and 
continues to analyze the map. 

Action: Correct the conflicting specification of 

attributes in the ATTRB operand and reassemble 
map. 

DFHBM0023 IC REQUESTED FOR A PROTECTED FIELD 



Severity : 
Meaning: 

Action: 



The DFHMDF ATTRB=parameter macro instruction 
reguested insertion of the cursor within a 
protected field. CICS accepts the request and 
continues to analyze the map. 

Ensure the validity of the request for this 
field. If invalid, correct and reassemble map, 



DFHBM0024 ASKIP IMPLIES xxxxxxxx 



Se verity : 
Meaning: 



The DFHMDF ATTRB=parameter macro instruction 
specified two attributes, one of which implied 
the other; for example, ATTRB= (ASKIP, PROT) where 
ASKIP includes PROT. CICS uses the more 
emcompassing attribute and continues to analyze 
the map. 
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A cti on: If the more encompassing attribute is acceptable, 
no action is necessary. Otherwise, correct 
the ATTRB specification and reassemble map. 



DFHBM0025 BRT IMPLIES DET 



Sev e rity : 
leaning : 

Action: 



The DFHMDF ATTRB=parameter macro instruction 
specified the BRT attribute which also implies 
the DET attribute. CICS uses the BRT attribute 
and continues to analyze the map. 

If the BET attribute is not required for this 
field, change the ATTRB specification and 
reassemble map. 



DFHBMC026 PEOT AND NDM IMPLY ASKIP 



Severity; : 
Meaning: 

Action: 



The DPHMDE ATTRB=parameter macro instruction 
specified PROT and NDM. The combination of 
these two parameters creates a field that also 
has the ASKIP attribute. 

No action is necessary; this message is 
informative only. 



DEHBM0027 ATTRIBUTE JXXXXXXX REPEATED. IGNORED. 



Severity : 
M ean ing : 

Action: 



The DFHMDF ATTRB= parameter specification contains 
the repetition of an attribute. CICS accepts 
the repetition without action and continues 
to analyze the map. 

Eliminate the repetition to remove the error 
message (if reguired) . 



DFHBMC028 DUPLICATE TYPE OPTION IGNORED 

Severity ; 

Meaning: A duplicated map TYPE specification was 
encountered and ignored. 

Action: No action message is necessary; this message 
is informative only. If desired, remove the 
duplicate specification before reassembling 
the map. 

DFHBMC029 INVALID TYPE SPECIFIED; OUT ASSUMED BY DEFAULT 

Severity: 8 

Meaning : A type specification was found which was not 
IN, OUT, ERASE, WAIT, MAP, or SAVE. OUT is 
assumed by default. 
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Ac ti on : If OUT is not an acceptable default, correct 
the error and reassemble the map. 

DFHBM0030 MAPNAME IS GT 7 CHARS; TRUNCATED 

Severity : 1 2 

Mea ni ng; A map name greater than seven characters was 

encountered and truncated to seven characters. 

Acti on: Correct the map name and reassemble the map. 

DFHBM0031 DATA = SPECIFIED INCORRECTLY; NO IS ASSUMED AS DEFAULT. 

Severity : 8 

Mean ing: A data specification was encountered which was 
not YES, NO, or ONLY. DATA=NO is assumed. 

Action: If NO is not an acceptable default, correct 

the DATA specification and reassemble the map. 

DFHBM003 2 DATA SPEC NOT REQUIRED WITH THIS TYPE; IGNORED. 

Severi ty : 4 

Meaning: Initial DATA was specified for a map which is 
not specified as an output map. The 
specification is ignored. 

Action: If it is desired that an output map be generated, 
change the TYPE specification to OUT and 
reassemble the map. 

DFHBM0033 CURSOR POSITION REQUIRES TYPE=OUT; THIS REQUEST IGNORED. 

Severity: 4 

Meaning: A cursor specification was provided for a map 

which was not an output map. The specification 
is ignored. 

A ct ion: If the map TYPE was specified incorrectly, 

change the specification to OUT and reassemble 
the map. 

D7HBM0034 MAPADR SYMBOL GT 8 CHARS. 

Severity: U 

Meaning: The MAPADR operand specified a name greater 
than eight characters. Only the first eight 
will be used to address the map. 

Action: Correct the MAPADR specification and reassemble 
the map. 
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DFHBM0035 INVALID LANGUAGE ASSEMBLER ASSUMED. 

Severity : 4 

Meaning: The LANG operand was not ASM, COBOL, or PL1. 
BMS assumes LANG=ASM. 

Action: If the language desired is not Assembler, correct 
the LANG specification and reassemble the map. 

DFHBMC036 INPUT SPEC WITH INCONSISTENT OPERANDS; INPUT, WAIT ASSUMED. 

Se ve ri ty. : 4 

Meaijing: TYPE=INPUT was specified along with OUT, ERASE, 
or MAP. These combinations are inconsistent 
and only INPUT is processed. 

Action: If some other specification is desired, correct 
the TYPE specification and reassemble the map. 

DFHBMC037 OUTPUT SPEC WITH INCONSISTENT OPERANDS; OUTPUT, WAIT ASSUMED. 

Se ver i ty : 4 

M ea ning: TYPE= (OUT, MAP) was specified which is 
inconsistent. 

Action: Correct the TYPE specification and reassemble 
the map. 

DFHBM0038 ERASE SPEC WITH INCONSISTENT OPERANDS; OUTPUT, ERASE, WAIT 
ASSUMED. 

Severity : 4 

M eanin g: A) Either TYPE= (ERASE, MAP) was specified or 

B) TYPE= (ERASE) was specified without OUT. 

Action: Correct the specification and reassemble the 
map. 

DFHBM0039 SAVE REQUIRES OUT; SAVE IGNORED 

S e v er i ty : 4 

Meaning: The TYPE operand specified SAVE but not OUT. 

Action: Correct the specification and reassemble the 
map. 

BFHBMC040 INVALID CURSOR POSITION DEFAULTS TO ZERO 

Severity : 4 

Meaning: The cursor keyword specified a value less than 
or greater than 1919 and therefore invalid 
for the 3270. 
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Ac tio n: Correct the specification and reassemble the 

map. 

DFH.BMC0M CURSOR POSITION REQUIRES 3270 Model 2 

S ever ity : 

Mea ni ng; The cursor specification is between 480 and 

1919 and therefore only valid for a 3270 Model 
2. 

Action: Do not try to use this map on a 3270 Model 1 
or unpredictable results will occur. 

DFHBM00H2 DATA = NOT SPECIFIED; NO IS ASSUMED AS A DEFAULT. 

Severity : H 

Meaning: DATA= was not specified for a TYPE=OUT 
specification. DATA=NO is assumed. 

Action : If NO is not an acceptable default, correct 

the DATA specification and reassemble the map. 

DFEBM9999 TFRECOVERABLE ERROR ENCOUNTERED BY DFHMDI 

Severity : 1 6 

Meaning.: The DFHMDI macro instruction encountered an 
irrecoverable situation during map analysis. 
CTCS abandons any further map analysis. 

Action: Examine the map specification carefully for 
invalid parameters and see that the macro 
instructions are properly ordered. Correct 
any errors and reassemble map. If the error 
persists, contact your IBM Representative after 
ensuring the availability of (1) a listing of 
the map analysis with the error messages and 
(2) the input causing the error message to be 
generated. 
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APPENDIX E: TRANSLATE TABLES FOP THE 2980 



This section contains translate tables for the following components 
of the 2980 General Banking Terminal System: 

1. 2980 Teller Station Model 1 

2. 2980 Administrative Station Model 2 

3. 2980 Teller Station Model 4 

The line codes and CPU codes listed in these tables are unique to 
CTCS and are represented as standard EBCDIC characters. 
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2980-1 CHARACTER SET/TRANSLATE TABLE 



KEY 


ENGRAVING 


PRINTING 


LINE 


CPU CODE 


High 
Level 


No. 


Top(LC) Front (UC) 


Numeric (LC) Alpha (UC) 


Code 


Numeric (LC) Alpha (UC) 


Lane. ID 





MSG 

ACK 


1 


I 


1 


Fl 


AA 


Fl 


1 


1 


SEND 
AGA 1 N 


Q 


R 


Q 


D8 


D9 


D? 




2 


CORN 


A 


C 


A 


CI 


C3 


CI 




3 


HOLD 
OVERRIDE 


2 


H 


2 


F2 


C8 


F2 




U 


VOID 


Z 


V 


1 


E9 


E5 


E9 




5 


ACCT 
IIIQ 


W 


Q 


W 


E6 


D8 


EB 




6 


ACCT 
TFR 


S 


T 
f 


s 


L2 


AN 


L2 


2 


7 


CIF 


3 


C 

F 


3 


F3 


AC 


C3 


3 


S 


MISC 


X 


M 


X 


E7 


AD 


E7 


4 


9 


CLSD 
ACCT 


E 


X 


E 


C5 


E7 


C5 




10 


no 

BOOK 


D 


e 


D 


Ck 


AE 


Ck 


5 


11 


140 RT 
LOAN 


1* 


¥ 


h 


FU 


AF 


fk 


6 


12 




C 


* 


C 


C3 


BO 


C3 


7 


13 


NEU 
ACCT 


R 


A 


R 


D9 


Bl 


D9 


8 


lit 


BOOK 
GAL 


F 





F 


C6 


B2 


C6 


9 


15 


INST 
LOAN 


5 


I 


5 


F5 


B3 


F5 


10 


16 


SPEC 
TRAM 


V 


S 

e 


V 


E5 


B4 


E5 


11 


17 


SAV 
BOND 


T 


B 


T 


E3 


BS 


E3 


12 
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2980-1 CHARACTER SET/TRANSLATE TABLE 



KEY 
No. 


ENGRAVING 
Top(LC) Front (UC) 


PRINTING 
Numeric (LC) Alpha (UC) 


LINE 
Code 


CPU CODE 
Numeric (LC) Alpha (UC) 


High 
Level 
Lang. ID 


18 


SAV 


G 


S 


G 


C7 


B6 


C7 


13 


19 


XMAS 
CLUB 


6 


"c 


6 


F6 


B7 


F6 


14 


20 




B 




B 


C2 


4B 


C2 




21 


DDA 


Y 


D 


Y 


E8 


B8 


ES 


15 


22 


Si 


H 


09 


H 


CS 


B9 


C8 


16 


23 


MON 
ORD 


7 


M 


7 


F7 


BA 


F7 


17 


2i» 





N 





N 


D5 


FO 


D5 




25 


7 


U 


7 


u 


El* 


F7 


El* 




26 


1* 


J 


i» 


J 


Dl 


F4 


Dl 




27 


CSHR 
CHK 


8 


1 


8 


F8 


BB 


F8 


18 


28 


1 


M 


1 


M 


Dl* 


Fl 


Dl* 




29 


8 


1 


8 


1 


C9 


F8 


C9 




30 


5 


K 


5 


K 


L2 


F5 


D2 




31 


CASH 
RECD 


9 


C 


9 


F9 


BC 


F9 


19 


32 


2 


' 


2 


' 


6B 


F2 


6B 




33 


9 





9 





06 


F9 


D6 




31* 


6 


L 


6 


L 


D3 


F6 


D3 
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2980-1 CHARACTER SET/TRANSLATE TABLE 



! 

KEY 
No. 


ENGRAVING 
Tod(LC) Front (UC) | 


PRINTING 
Numeric (LC) Alpha (UC) 


LINE 
Code 


CPU CODE 
Numeric (LC) Alpha (UC) 


High 
Level 
Lang. ID 


35 


UTIL 
BILL 





U 





F0 


E4 


F0 




36 


3 




3 




i*B 


F3 


1*B 




37 


UEP 

+ 


P 


+ 


P 


D7 


4E 


D7 




38 


UITH 


$ 


- 


$ 


5B 


60 


5B 




39 


FEES 


- 


F 


- 


60 


C6 


60 




1*0 


TOTL 


/ 


T 


/ 


61 


1:3 


Gl 




1*1 


CASH 
hi 




1 




5C 


BD 


5C 


20 


1*2 


CASH 
CHK 


# 


5 


# 


7B 


BE 


7B 


21 


U3 


VAL 


a 


A-K 


& 


50 


STATION 
ID 


50 




I*U 


TAB 








05 


05 


05 


TABCHAR 


1*5 


ALPHA 
ENTRY 








36 








.6 


nUMER 1 C 
ENTRY 








06 




\ 




1*7 


SEND 
1 








26-ETB 
03-ETX 




| 




1*8 


RETURN 








15 


15 


15 


JRNLCR 


U9 


HUMERI C 
ENTRY 








06 








50 


SPACE 








1*0 


1*0 


1*0 




58 


MSGLIGHIT 
1 








17 


17 


17 


MSGLITE 
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2980-2 CHARACTER SETARANSLATE TABLE 



KEY 


ENGRAVING 


PRINTING 


LINE 


CPU CODE 




High 
Level 


No. 


Tod(LC) Front (UC) 


Numeric (LC) Alpha (UC) 


Code 


Numeric(LC) Alpha 


UC) 


Lang. ID 





1 




1 


= 


Fl 


Fl (1) 


7E ( 


= ) 




1 


Q 




q 


Q 


D8 


98 (q) 


D8 


Q) 




2 


A 




a 


A 


CI 


81 (a) 


CI 


A) 




3 


2 




2 


< 


F2 


F2 (2) 


l*C 


<) 




t* 


Z 




z 


Z 


E9 


A9 (z) 


E9 


Z) 




5 


W 


C3 

2: 


w 


W 


E6 


A6 (w) 


E6 


w) 




6 


s 


:> 
< 


s 


s 


E2 


A2 (s) 


E2 ( 


s) 




7 


3 


UJ 


3 




F3 


F3 (3) 


5E 


;) 




8 


X 


o 
en 


X 


X 


E7 


A7 (x) 


E7 


X) 




9 


E 


>■ 


e 


E 


C5 


85 (e) 


C5 


E) 




10 


D 


o 


d 





Ck 


31* (d) 


Cl* 


D) 




11 


1* 




k 




F4 


Fit (1*) 


7A 


:) 




12 


C 




c 


C 


C3 


S3 (c) • 


C3 


e) 




13 


R 




r 


R 


09 


n (r) 


D9 


R) 




11* 


F 




f 


F 


C6 


86 (f) 


C6 


F) 




15 
16 


5 
V 


o 

> 
< 

o 


5 
V 


% 
V 


F3 
E5 


F5 (5) 
AS (v) 


ec 

E5 


%) 
V) 




17 


T 


1— 


t 


T 


E3 


A3 (t) 


E3 


T) 




18 

19 


G 
6 


o 
u. 

UJ 


6 


G 


C7 
F6 


87 (g) 
F6 (6) 


C7 
7D 


G) 




20 


B 


o 

2: 


b 


B 


C2 


S2 (b) 


C2 


B) 




21 


Y 




y 


Y 


E8 


A8 (y) 


E8 


Y) 




22 


H 
> 




h 


II 


C8 


88 (h) 


C8 


(») j 




23 


7 




7 


> 


F7 


F7 (7) 


6E 


>] I 




2k 


N 




n 


N 


D5 


95 (n) 


D5 


(N) 




25 


U 




u 


U 


El* 


Alt (u) 


El* 


(u) ; 

i 


1 



268 



2980-2 CHARACTER SET/TRANSLATE TABLE 



2 of 2 



KEY 


ENGRAVING 


PRINTING 


LINE 




CPU CODE 




High 
Level 


No. 


Tod(LC) Front (UC) 


Numeric (LC) Alpha (UC) 


Code 


Numeric(LC) Alpha 


(UC) 


Lang. ID 


26 


J 




j 


J 


Dl 


91 


(j) 


Dl 


(J) 




27 


8 




8 


8 


F8 


F8 


(8) 


5C 


(*) 




28 


M 




in 


M 


Ul* 


91* 


(m) 


Dl* 


(K) 




29 


1 




i 


1 


C9 


89 


(i) 


C9 


(I) 




30 


K 




k 


K 


02 


92 


(k) 


D2 


(K) 




31 


( 

9 


C3 


9 


( 


F9 


F9 


(9) 


1*0 


(0 




32 


1 


> 
< 


/ 


1 


6B 


6B 


(,) 


1*F 


(1) 




33 





o 








D6 


96 


(o) 


D6 


(0) 




3U 


L 


1— 
o 


1 


L 


03 


93 


(1) 


D3 


(L) 




35 


) 



u. 
>- 
l_J 





) 


F0 


F0 


(0) 


5D 


0) 




36 




o 




- 


It a 


i*B 


(.) 


5F 


C) 




37 


P 




P 


P 


D7 


97 


(p) 


D7. 


(P) 




38 


i 
$ 




$ 


i 


5B 


5B 


(S) 


5A 


(!) 




39 


- 




- 


_ 


60 


60 


(-) 


6D 


(_) 




UO 


/ 


o 


/ 


7 


61 


61 


(/) 


6F 


(?) 




1*1 


1 


> 
< 


@ 


£ 


5C 


7C 


(e) 


i+A 


U) 




1*2 


# 


C3 


# 


» 


7B 


7B 


(#) 


7F 


(") 




1*3 


+ 


t- 

o 


& 


+ 


50 


50 


(a) 


i*E 


(+) 




1+1* 


TAB 


U- 

;- 






05 


05 




05 






1+5 


LOCK 


o 






36 


36 




36 






1*6 


SHIFT 








06 


06 




06 






1*7 


BACKSPACE 








16 


10 




16 




BCKSPACE 


1+8 


RETURN 








15 


15 




15 






1*9 


SHIFT 








06 


06 




06 






50 


(SPACE) 








1*0 


1*0 




1+0 






53 


SEND 








26-ETB 
$3-ETX 
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KEY 
No. 


ENGRAVING 
Tod(LC) Front(UC) 


PRINTING 
Numeric (LC) Alpha (UC) 


LINE 
Code 


CPU CODE 
Numeric (LC) Aloha (UO 


High 
Level 
Lang. ID 





CK 
$ 




£ 




D9 


BC 


60 


19 


1 




Q 


L 


Q 


D3 


D3 


D8 




2 




A 


A 


A 


CI 


CI 


CI 




3 


CK 





C 





C9 


B7 


C9 


14 


k 




Z 




Z 


E9 


4B 


E9 




5 




W 


* 


W 


E6 


5C 


E6 




6 




s 


$ 


s 


E2 


SB 


E2 




7 


IMD 
2 


1 


1 


1 


5B 


4F 


Fl 




8 




X 


B 


X 


E7 


AE 


E7 


5 


9 




E 


E 


E 


C5 


C5 


C5 




10 




D 


? 


D 


Ck 


6F 


Ck 




11 


IMD 


2 


M 


2 


kB 


D4. 


F2 




12 




C 


C 


C 


C3 


C3 


C3 




13 




R 




R 


60 


60 


D9 




1U 




F 


F 


F 


CC 


C6 


C6 




15 


CODE 


3 


I 


3 


E8 


BB 


F3 


18 


1C 




V 


V 


V 


E5 


A0 


E5 


22 


17 




T 


A 


T 


E3 


Al 


E3 


23 

t 

il .1 
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KEY 


ENGRAVING 


PRINTING 


LINE 


CPU CODE 


High j 
Level I 


No. 


TodCLC) Front (UC) 


Numeric (LC) Alpha (UC) 


Code 


Numeric (LC) Aloha (UC) 


Lang. ID 


18 




G 


G 


G 


C7 


C7 


C7 


____ __^__ 


19 


AMT 


U 


$ 


t* 


5C 


BE 


FU 


21 


20 




B 


B 


B 


C2 


C2 


C2 




21 




Y 


/ 


Y 


61 


61 


E8 




22 




H 


P 


H 


D7 


D7 


C8 




23 


OB 


5 




e 


5 


D8 


B2 


F5 


9 


21* 




N 


N 


N 


D5 


D5 


D5 




25 







H 


U 


El* 


AF 


El* 


6 


26 




J 


J 


J 


Dl 


Dl 


Dl 




27 


ACCT 


6 


# 


6 


C8 


7B 


F6 




28 




H 


X 


M 


DU 


R7 


Dl* 




29 




1 





1 


D6 


D6 


C9 




30 




K 


K 


K 


D2 


D2 


D2 




31 


7 


7 


7 


7 


F7 


F7. 


F7 




32 


... 


... 


/ 


/ 


6B 


BLANK 


6B 




33 


h 





1* 





Fl* 


F4 


D6 




31* 


1 


L 


1 


L 


Fl 


Fl 


D3 




» — 














, 
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KEY 
No. 


ENGRAVING 
TodOLC) Front (UC) 


PRINTING 
Numeric (LC) Alpha (UC) 


LINE 
Code 


CPU CODE 

Numeric(LC) Aloha (UC? 


High 
Level 
Lang. ID 


35 


8 


8 


8 


8 


F8 


F8 


F8 




3C 












F0 


F0 


l*B 




37 


5 


P 


5 


P 


F5 


F5 


D7 




38 


2 


^ 


2 


$ 


F2 


F2 


5B 




39 


9 


9 


9 


9 


F9 


F9 


F9 




1*0 


... 


... 


+ 


• 


7B* 


BO 


7B 


7 


kl 


6 


* 


6 


* 


F6 


F6 


5C 




1+2 


3 


# 


3 


# 


F3 


F3 


7B 




1*3 


VAL 


& 


A-K 


& 


50 


50 


50 




1*1* 


TAB 








05 


05 


05 




1*5 


ALPHA 








36 








1*6 


NUMERIC 








OC 








k7 


SEND 








26-ETB 
03-ETX 








1*8 


RETURN 








15 


15 


15 




1*9 


NUMERIC 








06 








50 


SPACE 








1*0 


1*0 


1*0 




51 


FEED 
OPEN 








01* 






OPENCH 



27 2 



9,19,33 
231-235 



INDEX 

ABCODE 19,61,67-68 

ACCA INTERRUPT STATUS WORD 157 

ACCEPTABLE ADDRESSING METHOD 101 

ACCESS DEVICES 111 

ACCESS METHODS 83 

ACCESS, INDIRECT 112 

ACCTNO 89-90 

ACTIVITIES, TYPES OF CONCURRENT 3 

ADDING RECORDS 112,181 

ADDITION OF KEYED FIXED-LENGTH RECORDS 

ADDITIONS, FIXED-RECORD 182 

ADDRESS XCTL 9 

ADDRESS, AREA 17,87,95,117,128 

ADDRESS, BCA 166,168 

ADDRESS, FIOA 111 

ADDRESS, STRG 73 y 

ADDRESS, PRELOAD PCB 1 S3 y 

ADDRESS, STORE FWA 109 

ADDRESS, USER FCA 18 

ADDRESS, PRELOAD WORKAREA 191 

ADDRESS, PROGRAM ENTRY 9 

ADDRESS, DATA 225 y 

ADDRESS, LINE 157-158 

ADDRESS, SYMBOLIC BASE 

ADDRESS, TRANSIENT DATA 

ADDRESS, USER FCA 18 

ADDRESSABILITY 11,25,31-31,10-13,15,80,82,87,190,198,207 

ADDRESSABILITY 15,31,7 8-79,81-82,89-97,99-100, 

109-110,185,198 
ADDRESSABILITY FWA 89-91,91,97,106 

ADDRESSABILITY TCA 89-91,91,97,99,103,105 

ADDRESSES CF CICS PROGRAMS 17 

ADDRESSES OF CICS STORAGE AREAS 38 

ADDRESSES OF SSA'S 185,187 

ADDRESSES OF THE ACTUAL LOCATIONS 39 

ADDRESSES, PCB 183-181,187-189,191-192,191,193 

ADDRESSES, TASK STORAGE CHAIN 18 

AID'S * 206 
ALARM 199,201 

ALIGNMENT 17,171 

ALPHAMERIC 200 

ALTERED RECORD 167,169 

ALTERNATE ACTION 159 

ALTERNATE STATION 163 

ALTERS 6,13,19,60,66,159,201 

ANS COBOL APPLICATION PROGRAM 10,37,163,205-206 

ANS COBOL EXAMPLE 163 

ANS COBOL PROGRAMMER 9,32 

APPLICATION CONTROL BLOCK 181 

APPLICATION KEYWORDS 9 5 

APPLICATION LOGIC 195 

APPLICATION PROGRAM, EXIT PCINTS OF AN 6 

APPLICATION PROGRAM CONTAINS BINARY ZEROS 78 

APPLICATION PROGRAM LISTING 10 

APPLICATION PROGRAM, EXAMPLE OF AN 82 

APPLICATION PROGRAM, SERIALLY REUSABLE PORTION OF AN 6,60 

APPLICATION PROGRAMMER 3,9,10,23,56-59,77-78,82,87,93,96, 

98,99,111,158,160,181,186 
APPLICATION PROGRAMMING CONSIDERATIONS 77 

APPLICATION PROGRAMS 7,10,15,78,81,155,159,178 



AREAS, CONTROL 13,32,50-51 

AREAS, DL/I 183 

AREAS, TRANSACTION-ORIENTED STORAGE 69 

AREAS, I/O 6,9,13-11,36,38,13,55,100 

AREAS, PROGRAM STORAGE 72 

AREAS, PARAMETER 18 

AREAS, STATIC 70 

AREAS, SYMBOLIC MAP 198 

AREAS, TERMINAL STORAGE 70-72 

AREAS, TRANSACTION STORAGE 69,72 

AREAS, WORK 9,13,17,60,86,100,108,167,183,186-187 

ARGUMENT 109-110,177-181,183,186-187,191 

ARGUMENT TYPE 88 

ARGUMENT, LENGTH OF THE ' 53, 178 

ARGUMENT, SEARCH 108,112,175-179 

ASKIP 199-201 

ASKS 28,37,11 

ASM 197 

ASMTDLI 18 6 

ASSEMBLER 10,111 ,122,130,151,167,169,190-191 

ASSEMBLER LANGUAGE APPLICATION PROGRAM, EXAMPLE OF 

ASSEMBLER LANGUAGE, CASE OF 187,206 

ASSEMBLY, TIME OF 10 

ASSOCIATED BIT 75 

ASSOCIATED DATA RETENTION 132 

ASSOCIATED DMB'S 181 

ASSOCIATED TASK 18,69 

ASSOCIATED TASK, TERMINATION OF THE 55 

ASSUMED NUM ATTRIBUTE 201 

ATTACH 17-18 

AUTOANSWER 1 55 

AUTOCALL 155 

AUTOSKIP 206 

AUXILIARY- DATA, BLOCK SIZE OF TEE 131 

BANKING CHARACTERS 161 

BASE OPERAND, USE OF THE 198 

BASE VALUE 193 

BASED STRUCTURE 39 -1 3 , 1 6 3 , 1 9 8 

BASIC MAPPING SUPPORT 195,2 00,2 02 

BASIC TELECOMMUNICATIONS ACCESS METHOD 71 

BATCH PROCESSING SYSTEM 3 

BCA 1 67 

BCKSPACE 161 

BDAM 1 1 2 , 1 76 

BDLIIO 193-191 

BINARY FORM 133-131 

BINARY VALUE 79 

BINARY ZEROS 17,53,55,57-58,100-101,138,159 

BINARY ZEROS, TWO-BYTE FIELD OF 116,126,116,195 

BLANK CHARACTER 11,196-197,201 

BLANKS 30,39,15,100,181,196,199-201,201 

BLANKS, EBCDIC 55,58,96 

BLK 180 

BLKKEYL 181 

BLKSIZE 17 6 

BLL 32,38-39 

BLL LIST 185 

BLL TABLE 192 

BLOCKED BDAM DATA SETS 101-102 

BLOCKED DAM DATA SET 8 8 
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183,191,195,197,203 
APPLICATION PROGRAMS, GROUP OF 215 

APPLICATION PROGRAMS, MODULARITY OF 6 

APPLICATION PROGRAMS, REQUEST OF 16,175 

APPLICATION PROGRAMS, TESTING OF 2 

APPLICATION, SINGLE 121 

APPLICATIONS 1,3-1,6,81,125,155,195,215 

AREA DEFINITIONS 166,169 

AREA PREFIX 187 

AREA TWAIND 166 

AREA, ACQUIRED STORAGE 58 

AREA, ADDRESSED 31 

AREA, INPUT/OUTPUT 15,57,193 

AREA, AVAILABLE DYNAMIC 121,129 

AREA, BATCH CONTROL 167 

AREA, CICS INPUT 118 

AREA, CICS TRANSACTION WORK 32 

AREA, COMMON SYSTEM 13,15,17,21,33,39-10,56, 

69,71-73,131 
AREA, COMMON WORK 33 

AREA, COMMUNICATIONS 69 

AREA, CURRENT 169 

AREA, MESSAGE 29,38 

AREA, DL/I I/O 191 

AREA, DROP WRKREG TERMINAL INPUT/OUTPUT 25 

AREA, ENTIRE WORK 17 

AREA, EVENT CONTROL 50-51,138 

AREA, ■ FILE INPUT/OUTPUT .31,11,81,86 

AREA, FILE WORK 22,32,35,12,61,81,86,92,95,99,112 

AREA, FOUR-BYTE STORAGE 138 

AREA, INITIATOR CONTROL 18 

AREA, INTERMEDIATE STORAGE 6,6 

AREA, LENGTH OF THE 73 

AREA, NEW STORAGE 31,57-58,95 

AREA, ONE-BYTE RESERVED DATA 201 

AREA, OPTIONAL TRANSACTION WORK 1 8 

AREA, OUTPUT 26,39,15,116 

AREA, OUTPUT DATA 76 

AREA, OUTPUT STORAGE 79 

AREA, PASSBOOK 159-160 

AREA, SIZE OF THE WORK 17 

AREA, SYMBOLIC NAME OF THE 117 

AREA, SYSTEM 11 

AREA, TASK CONTROL 11,15,18,21,33-31,10,16,56,60,69,71-71 

AREA, TASK EXTENSION 69,71-73 

AREA, TCASCSA FILE INPUT/OUTPUT 25 

AREA, TEMPORARY STORAGE INPUT/OUTPUT 11,27,36,13,59 y 

AREA, TERMINAL INPUT/OUTPUT 13,11,31,33-31,10-11,61,165 

AREA, TRANSACTION WORK 6,18,23,25,31,10,60-61 

AREA, TRANSIENT DATA I/O 118 

AREA, TRANSIENT DATA INPUT 11,35,12,165 

AREA, TRANSIENT DATA OUTPUT 11,27,36,12 

AREA, TRANSIENT DATA RECORD STORAGE 59 

AREA, USER 118 

AREA, USER-DECLARED FILE RECORD 12 

AREA, USER-DEFINED COMMON WORK 17 

AREA, USER-PROVIDED DATA 119 

AREA, USER-PROVIDED STORAGE 127-128 

AREAS 17-18,72,166-169,171,183-188,191,198,205 

AREAS, CICS STORAGE 13,15-17,23,32,39,192 

273 



BLOCKED RECORDS 26,86 

BLOCKED SYSIN 71 

BMS 191-195,197,202-205 

BMSMAPBR 198 

BOOK-FOR-PRESENT-WRITE 163 

BOOK-PRESENT-WRITE 1 63 



BPCB1 

BPCB2 

BRANCH 

BROWSE 

BROWSING 

BRT 

BSSADS 

BTAM 

BUFFER 

BUFFER SIZE 

BUFFER, COMMON 

BYTE, ATTRIBUTE 

BYTE, CCNTBOL 

BYTE, LENGTH 

BYTE, RESERVED 



193-191 
193-191 

156 

26,12,81,101,101,106-107,113 
83 



199-200 
193-191 
71,75,151 

75-77,155,158,199-200,201 
160-161 
161 
196,200,201 
168 
171 
195 
BYTES 79,116,125-126,138,116,168,170-172,177,186 

BYTES OF THE FOUR-BYTE TCATCQA 53 

BYTES OF THE OUTPUT AREA 117 

BYTES, NUMBER OF 21,57-59,79,82,171 

CALCULATE 57,136,139,111,113,112,116,115 

CALL 6,183-186,188-189,193 

CANCEL 131,136,138,111,111,119-150 

CANCEL MACRO REQUEST 138 

CANCELLATION 135,119-150 

CARD 10-11 

CARD COLUMN 16 11 

CARD READERS 2,71 

CARD, COMMENTS 10 

CARD, CONTINUATION 11 

CARD, EXEC 10 

CARD, PROCESS 10 

CARD, TITLE 10 

CARDS, CVEFRIDING DD 71 

CARRIAGE RETURN/LINE FEED 199,201 

CARRIAGE RETURNS 160 



CATLOG 

CBUFF 

CCB'S 

CCC 

CHAIN 



176-177 
75,161 
50 



200 



76-77 

15,31,56,82 
CHAINED OFF 70-71 

CHAINED STORAGE AREAS, SERIES OF 
CHAP 17-19 

CHAR 95, 97 

CHAR, DUMMY 119 

CHARACTERISTICS, DEVICE-DEPENDEKT 
CHARACTERISTICS, FIELD 196,201 

CICS CONSOLE 157 

CICS CCNTRCL AREA 119 

CICS CONTROL INFORMATION, PORTICN OF THE 
CICS CCNTRCL MODULES 17 

CICS CONTROL SECTION 92 

CICS CCNTRCL TABLES 70 

CICS DATA SETS 71 



112 

180 

170,179 
24,33.39, 154 



6,10-11,60, 19*, 213 
46,69-70 

114,116 

203,205 

197 
15,19,24,58,174 
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CICS DESTINATIONS 115 

CICS DUMP 70 

CICS DUMP CODES 251 

CICS ENTRY 218 

CICS ENVIRONMENT 52 

CICS EPROR CLASSES 

CICS FEATURES 170 

CICS FILE CONTROL 

CICS FILE MANAGEMENT 

CICS INITIALIZATION 

CICS LIBRARIES 13 

CICS MACRO INSTRUCTIONS 

CICS MANAGEMENT MODULES 

CICS NUCLEUS 2<!,33,39 

CICS PARTITION/REGION 

CICS PREPROCESSOR 205 

CICS PROGRAM LIBRARY 

CICS PROGRAM LOAD LIBRARY 

CICS STORAGE MANAGEMENT 

CICS SUBTASKS 18 3 

CICS SUPERVISORY 10-11 

CICS SYSTEM CONTROL 18,25 

CICS SYSTEM SERVICES 132,154 

CICS TASK 251 

CICS TEMPORARY STORAGE MANAGEMENT 144,148 

CICS TEMFORARY STORAGE MANAGEMENT FACILITY 14 

CICS TIME MANAGEMENT 1,133 

CICS TIME-CRDERED EVENT 138 

CICS-DL/I INTERFACE 183 

CICS/DOS 6,10-11,78,112,120,134,182 

CICS/DOS-ENTRY SYSTEM 32,56,65,69-73,124,205 

CICS/OS SYSTEM 74,182 

CICS, ABNORMAL TERMINATION OF 118 

CICS, APPLICATION PROGRAMS RUNNING UNDER 61 

CICS, APPROPRIATE 86 

CICS, BASED STRUCTURES OF 9 

CICS, CONTROL OF 39,114,139 

CICS, EXECUTION OF 63-65 

CICS, OPERATION OF 6,17,120 

CICS, OPERATIONAL 153 

CICS, OS SUBTASK OF 1 83 

CICS, RELINQUISH CONTROL OF 50-52 

CICS, RELOCATION OF 9 

COBOL APPLICATION PROGRAM, EXAMPLE OF CICS ANS 

COBOL, ANS 161,163-164,186,191,195,198,205 

CODE DOCUMENTATION, PURPOSE OF 59 

CODE TRANSLATION 74 

CODE, ABNORMAL TERMINATION 67 

CODE, ACTUAL PL/I 10 

CODE, AI STATUS 188-189 

CODE, ASCII TRANSMISSION 155 

CODE, DEFAULT TRANSACTION 66 

CODE, DLPA ABEND 184 

CODE, FOUR-CHARACTER ABNORMAL TERMINATION 67-6 

CODE, FOUR-CHARACTER TRANSACTIOK 156 

CODE, I/O EVENT ERROR 112 

CODE, LINE 112 

CODE, MULTIPUNCH 113,123,131 

CODE, OPERATION 186 

CODE, SOURCE 39 



38,198 



CSA, USER PORTION OF THE 69,71-73 

CSA, WORK AREA PORTION OF THE 40 

CURRENT CLOCK TIME 134,136,139,141-142,145 

CURSOR 76,79,82-83,201,203-204 

CWA 17,33,69,71-73 

CWTR 165-166,168-169 

DAM 83,87-88,93,100,180 

DAM BLOCK, PHYSICAL IDENTIFIER OF THE 180 

DAM DATA SETS 88,101,104,176,180-182 

DAM NON-KEYED DATA SETS 112 

DAM ORGANIZED DATA SETS 170 

DAM RECORD IDENTIFICATION FIILD 177 

DASD 124,170,173-175 

DATA AREA 126,151-152,174,196,201 

DATA ATTRIBUTES 196 

DATA BASE 3-4,7,87-88,101,176,183,188 

DATA BASE CONSIDERATIONS 

DATA BASE/EATA COMMUNICATION SYSTEM 1, 4 

EATA BASES, ADDRESSES OF THE PCB'S OF THE 183 

DATA CHARACTER 74,200 

DATA CHECK MESSAGE 157 

DATA COLLECTION 1-2,124-125,154 

DATA DIVISION 9,11,32,38,161,237 

DATA ENTRY KEY 199,204 

DATA ENTRY KEYBOARD 200 

DATA FIELDS 32,195-196,199 

DATA HANDLING 160 

DATA INPUT 165 

DATA LANGUAGE/I 2,33,84,183 

DATA MANAGEMENT BLOCKS 184 

DATA MANAGEMENT SERVICES 6,10-11,32,39,46 

DATA MANAGEMENT TEMPORARY STORAGE SERVICES 46 

LATA RECORD 86,88,123,148,149,177 

DATA SET IDENTIFICATION 22 

DATA SET, CHARACTERISTICS OF THE 84 

DATA SET, DATA EASE 26 

DATA SET, LOGICAL RECORD OF THE 101 

DATA SET, SEGMENTED STRUCTURE OF THE 170 

DATA SET, SEGMENTS OF A 170 

DATA SET, SYMBOLIC NAME OF THE 96,100 

DATA SETS 112,114-115,122,169-170,173,175-178,180-181 

DATA SETS, DEBLOCKING OF THE 88 

DATA TRANSFER, COMPLETION OF 78 

DATA TRANSFER, DIRECTION OF 157 

DEBUGGING 214 



DEFAULT ACTION 


78 




DEFAULT ALIGNMENT 


171 




DEFAULT FIELDS 


204 




DEFAULT LOCATION 


201 




DEFAULT SEGMENT SET 


108 




DEFAULT SEGMENT SET 


NAME 


104 


DEFINITION, DYNAMIC 


STORAGE 


33,40 


DEFINITION, STATIC ! 


STORAGE 


24,33,39 



48,114-115,121 



DEFINITIONS, PCB 193 

DESTINATION CONTROL TABLE 

DESTINATIONS 2,77-78,114-117,121-123 

DET ATTRIBUTE 200-201 

DETECTION, SYSTEM STALL 1,132 

DEVICE, BUFFERED 75 

DEVICES, SEQUENTIAL 2,74,214 



203,205 



CODE, TERMINATION 

CODE, TRANSACTION 

CODE, UNIQUE 178 

CODE, USER-SPECIFIED 70 

CODE, 3270 DEVICE-DEPENDENT 194 

CODE, 3735 USING ASCII TRANSMISSION 77 

CODES, ERROR 112 

CODES, SPECIAL HEXADECIMAL 164-165 

CODES, REQUEST 23,153 

CODES, RESPONSE 96,98,111,113,122-123,130-131, 

144,143,146,151 
COMMON BUFFER 161 

COMMON WORK AREA, BEGINNING OF TEE 17 
COMMUNICATION CONTROL ADAPTER 157 
COMMUNICATION LINES 50,75,154 
COMMUNICATION, CONVERSATIONAI KODE OF 83 
COMMUNICATION, PROVIDE ADDITIONAL 165 
COMMUNICATIONS, REAL-TIME DATA BASE/DATA 3 
COMPATIBILITY 78,138,194 
COMPILER 1 

COMPILER, FULL ANS COBOL 32-33 
COMPLETE DUMPS, NUMBER OF 70 
COMPLETION 11,49-50,82,154, 156,203 
COMPLETION CODE POSTINGS 138 
COMPLETION, I/O 7 
COMPLETION, SUCCESSFUL 156 
COMPONENT SELECTION 158 
CONFIGURATION 22,58,77 
CONFIGURATION, BIT 55-56 
CONFLICTING ATTRIBUTES 259 
CONSIDERATION, PERFORMANCE 134 
CONSIDERATIONS, DEVICE 157 
CONSIDERATIONS, DEVICE-DEPENDENT 195 
CONSIDERATIONS, QUASI-REENTRANT 183 
CONSIDERATIONS, SYSTEM/7 156 
CONSIDERATIONS, 2260/2265 PROGRAMMING 157 
CONSIDERATIONS, 2770/2780 PROGRAMMING 158 
CONSIDERATIONS, 3735 155 
CONSOLE, SYSTEM 11,157 
CONTROL, DUMP 21,67-69,71-73 
CONTROL, FILE 83-84,93,95-96 
CONTROL, INTERVAL 132 
CONTROL, PASSBOOK 161 
CONTROL, TASK 18,46-47,56,132 

CONTROL, TEMPORARY STORAGE 27,56,59,124,127-128 
CONTROL, TRANSFER PROGRAM 64 

CONTROL, TRANSIENT DATA 27,59,114-115,117,215,228 

CONTROL, TS TEMPORARY STORAGE 21 7 

CONTROL, TERMINAL 74,157 

CONVENTION, INSTALLATION 52 

CONVENTION, NAMING 124 

CONVERSE 74-75,83,245 

COPY CONTROL CHARACTER 76 

COPYING 14-15,78 

CPU 46 

CPU TIME 50 

CPU, CONTROL OF THE 46 

CRDR 165,167-168 

CROSS-INDEX DATA SET 91-92,175 

CSA, FIELDS OF THE 17 



DFHBMS MACRO INSTRUCTION 199,202,205 

DFHBMSCA 206 

DFHCLEAR 2 06 

DFHCOVER MACRO INSTRUCTION 1 

DFHCSADS 24,32-33,40,44,54,193 

DFHDC 69,71,73-74,215,217 

DFHDUP 68 

DFHFC MACRO 22,184,186,190,192,194 

DFHFILL 164 

DFHFIOA 26,34,41,86 

DFHFWADS NAME 26 

DFHFWADS, 26,89-90,92,95,97,99,103,106,108,110 

DFHIC MACRO INSTRUCTIONS 23,138,141-144,152 

DFHKC 47,53,55,66,140 

DFHMDF MACRO INSTRUCTION 199,201-202 

DFHPC 19,29,63-66,123,131 

DFHPC, NAME 244 



DFHPC, NO 

DFHSAADS 

DFHSC 

DFHSYTCA 

DFHTACP 

DFHTC 

DFHTCA 

DFHTCADS 

DFHTCT 

DFHTCTTE 

DFHTD 

DFHTDIA 

DFHTDOA 

DFHTEP 

DFHTIOA 

DFHTS 

DFHTSIOA 

DIAL-UP 

DISCONNECT 

DISK 



244 
28,37,43-44 
19-20,22-23,58-59,80,194,215,217,234,238,241 
25 



73,115,251 
74-75,80,82,154-156,160 
33-34 
25,34,166-168 
157 

24,32-33,40,44,78,162 
115-116,118,120 

26,35-36,42, 118-119 
27,36,42-43,116 
73 
25,34,41,44,78,162,207 
23,28,125-130 

27,32,36,43,128 
157 

75,155,157,245 
2,68 



DISPATCHING PRIORITY 49 
DISPATCHING, TASK 17,133-134 
DISPLACEMENTS 9,172-173 
DIVISION, ENVIRONMENT 38 

DIVISION, PROCEDURE 38,89-91,94,97,99,103,105,162,192 
DL/I 2,33,84,183-184,186-194 
DL/I CALL 183-184,188-189 
DL/I INTERFACE 188 
DL/I PSEUDO- ABEND 183-184 
DL/I PSEUDO-ABEND CODE 99 2 184 
1 
DL/I REQUEST 189,191 
DL/I REQUEST HANDLER 183 
DL/I TASK 183 
DMB 184 
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DMB DIRECTORY 


184 


DMB POOL SPACE 


189 


DPGM 72 




DRK ATTRIBUTES 


200 


DUMMY RECORDS 


182 


DUMP CODES 251 




DUMP AREA 74 




DUMP DATA SET 67- 


68 
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DUMP MANAGEMENT 1,67-68,71 

DUMP MANAGEMENT TERMINAL SERVICES 
DUMP, FORMATTED STORAGE 67 

DUMP, NO 67 

DUMP, OUTPUT 67 

DUMP, PARTIAL 71-74 

DUMP, COMPLETE STORAGE 71 . 

DUMP, TRANSACTION STORAGE 7 

DUPDS 84-85,87,110-112,245-246 

DUPLICATE NAMES 124 

DUPLICATE RECORD 112,178 

DUPLICATES 83,112,178-179,215 

DUPLICATES DATA SETS, USE OF 178 

DYNAMIC STORAGE FOOL 8 

ECADDR 47,50-52,244 

ECB'S 50,155 

ELEMENT, PRINT 159 

ELEMENT, TYPE 160 



148 
78,112,155 

191 
134,147,151-152 
85-86,103,110-112 



183 



69,71-73 



END-OF-DATA 

END-OF-FILE 

END-OF-LIST 

ENDDATA 

ENDFILE 

ENQ 47,52-55 

ENTRY CONVENTIONS 

ENTRY LABELS 87,93,96,98,110-111,122,130,151 

ENTRY SPECIFICATIONS 112 

ENTRY, CONVERSATIONAL DATA 1 

ENTRY, DESTINATION CONTROL TABIE 

ENTRY, FILE CONTROL TABLE 178 

ENTRY, PCT 166,168 

ENTRY, TERMINAL 14,70 

ENTRY, TERMINAL CONTROL TABIE IINE 81 

ENVIRONMENT, CONVENTIONAL BATCH PROCESSING 

ENVIRONMENT, CONVERSATIONAL 81 

ENVIRONMENT, DB/DC 4 

ERASE 75-76,79-82,203 

ESETL 85,106-108,112 

EVENT CONTROL AREA, TIMER 

EVENT CONTROL AREAS, LIST OF 

EVENT CONTROL BLOCK 155 

EVENT, COMPLETION OF THE 

EVENT, WRITE 78 

EVENTS, LIST OF 51-52 

EXAMPLES, FROGRAM 231 

EXCEPTION, USER-WRITTEN 



139 



98,110,123,130,151 



EXCLUSIVE OPTIONS 199-200,204 

EXCLUSIVE USE 18 

EXIT ROUTINE TWAWA 166 

EXIT, CRDR 166 

EXIT, PARTITION/REGION 132 

EXPIR, CALC 147 

EXPIRATION TIMES 133-135,134,150 

EXPIRD 132,134,136,138,151-152 

EXTRAPARTITION 114,116,118 

EXTRAPARTITION DATA SETS 115,119-120 

EXTRAPARTITION MAGNETIC TAPE TATA SET 120 

EACADR 48 

FACCTL 48 

FACILITIES OF CICS/OS 33 



EWA, DATA PORTION OF THE 17 4 

FWA, DECLARATION OF THE 42 

FWA, NEW 93,95 

FWA, ORIGINAL 100 

FWACBAR 26,87,89-91,9 4-100, 102-103, 105, 107, 106, 109-11 

FWACEAR, INDEXAB 92 

FWACELL1 107-108 

EWACELL2 107-108 

GENERATE ADDITIONAL TRANSACTION STREAMS 214 

GENERATE I/O LIST 156 

GENERATION 219 

GENERATION TIME 17 

GENERATION, OFFLINE MAP 195,197 

GENERATION, SYSTEM 55 

GENERIC 100-101 

GENERIC KEY 100 

GET'S, ISSUE REPETITIVE 115 

GETAREA 85,95-97 

GETAREA REQUEST 93,95 

GETIME 132,134-135 

GETMAIN REQUEST 95 

GETMAIN WORKREG 20 

GETMAIN, CONDITIONAL 19 

GETNEXT 85,103,105-106,113 



100-102,104 



178- 179 
11 
113,123,131 
191 
11 

196 
202 
202 
202 

199,201-202,209,249 



GETNEXT REQUEST 

GETNEXT, 101,104 

GHU 1 92 

GISMO 

GONUMBER 

GOOD 

GOOD1 

GO STMT 

GROUPNAME 

GRPFLDAI 

GRPFLDAO 

GRPLO 

GRPNAME 

GU 194 

GXLBZQMR 137 

GXXX 187 

GXXX REQUEST 187 

HALFWORD BINARY FIELD 196 

HALFWORD OF THE SAA, SECOND 186 

HBIN 217-219,249 

HEX 1 80 

HEXADECIMAL 49,58,75,161 

HHMMSS, FORM 136-137,139,142,145 

BHMMSST, FORM' 17,134 

HIERARCHY 88,170,177 

HIERARCHY, TWO-LEVEL INDIRECT ACCESS 

HIGH-ORDER 187 

HIGHER DISPATCHING PRIORITY, TASKS OF A 

HIGHER LOGICAL LEVEL 6 4,66 

HIGHER PRIORITY, TASK OF A 50 

HIGHEST PRIORITY TASK 46 

HOLDPCF 163-164 

HOLDPCFB 163-164 

HONEOM 197,200,199,203-204 

I/O 14,107,183,185,187,190 

I/O BUPFER, CONTENTS OF THE 158 



FACILITIES, TEMPORARY STORAGE 152 

FACILITY, EXCEPTION HANDLING 110,122,130,151 

FACILITY, TRACE 216,218,217-218 

FACILITY, TRANSIENT DATA PURGE MACRO 114 

ICA 18 

FCACELL2 1 07 

ECADDR 47-48,243 

FCFIOBEX 112 

FCFIOEX 112 

FCT 83-8 4,86-8 8,92,9 5-96,100-101,112,180-181 

FDP RECORDS, BLOCK OF 155 

FDP RECORDS, TRANSLATION OF 77 

FDP'S 15 5 

FEATURE, ADJUSTMENT 133 

FEATURE, EOI DISABLE 165 

FEATURE, STALL PROTECTION 55 

FEATURE, SYNCHRONIZATION 133 

FEATURE, TIME ADJUSTMENT 135 

FEEDBACK 101 

FEOV 116,120-122,228,233,247 

FIELD, RECORD IDENT 89 

FIELD, RECORD IDENTIFICATION 102 

FIELDNAME 32 

FILE CONDITION 78 

FILE CONTROL REQUEST/RESPONSE, TYPE OF 23 

FILE CCNTRCL REQUESTS 111 

FILE CONTROL TABLE 86,92,172 

FILE CCNTRCL TABLE ROOT 170 

FILE MANAGEMENT TRANSIENT DATA SERVICES 46 

FILE SERVICES 17,84,86-37,92-93,96,98,100,104,110,190 

FILE, BDAM 183 

FINAL BLOCKS 155 

FIOA 14,22,26,34-3 5,41 ,84,86-88,98,111-112 

FIOAEAR 35,41,87 

FIXED-LENGTH RECORDS 170,182 

FORMAT, DECIMAL 180 

FORMAT, FIXED 174 

FORMAT, PACKED 88,101 

FORMAT, PACKED DECIMAL 17 

FORMAT, RECORD 170 

FORMAT, STANDARD VARIABLE-LENGTH 146 

FORMAT, USER-ESTABLISHED 17 

FOUR-BYTE FIELD 14,51 

FREEKB 197,199,203-204 

FREEMAIN 21,56,59-60,87 

FRSET 197,199,201,20 3-204 

FSET 199-201 

FUNCTION, DLI 194 

FUNCTION, MAPPING 205 

FUNCTION, PRELOAD 194 

FUNCTION, TASK DISPATCHING 13 9 

FUNCTIONS, CONTROL 19 8 

FUNCTIONS, OPTIONAL TASK 1 

FUNCTIONS, PRINTER 200,204 

FUNCTIONS, TASK 132 

FUNCTIONS, TRACE CONTROL 215,218 

FWA ADDR 109 

FWA CONTROL FIELDS 174 

FWA DSECT RECORD 1 DS 108 

FWA, ASSIGN 105,107-108 



IC 199-201,209 

IC ATTRIBUTE 201 

ICDADDR 134,144-150,149 

ID, NEW SEGSET 110 

ID, REQUEST 225 

ID, SOURCE TERMINAL 78 

ID, TRACE 2 20 

IDENT, DEST 235 

IDENTIFICATION 22,63-66,100-102,104,108,147,152,170 

IDENTIFICATION DIVISION 38 

IDENTIFICATION DIVISION CARD 10 

IDENTIFICATION ERROR 111 

IDENTIFICATION FIELD 22,104,182 

IDENTIFICATION WORD 156 

IDENTIFICATION, EIGHT-BYTE REQUEST 137,140,142 

IDENTIFICATION, FOUR- CHARACTER TERMINAL 157 

IDENTIFICATION, INITIAL PROGRAM 46 

IDENTIFICATION, MATCHING TERMINAL 143,146 

IDENTIFICATION, MATCHING TRANSACTION " 144,146 

IDENTIFICATION, NEW TRANSACTION 66 

IDENTIFICATION, OPERATOR 124 

IDENTIFICATION, RECORD 87,98,101,108,180 

IDENTIFICATION, REQUEST 152 

IDENTIFICATION, SEPARATE RECORD 88 

IDENTIFICATION, TELLER 163 

IDENTIFICATION, TRACK 182 

IDENTIFICATION, TRANSACTION 

143-144,146,148,156 
IDENTIFICATION, UNIQUE 152 
IDENTIFICATION, UNIQUE REQUEST 
IDERROR -122,125,127,129-130 
IDLE 79 

IMPLEMENTATION OF SYSTEMS 195 
IMPLEMENTATION TIME 1 
IMPLIED WAIT 80 
IMS 183 
IMS/360 2,84 
INAREAL 81 

INCREMENT TERMINAL DATA LENGTH 234,236 
INDEX 22,84,87-88,91-9 2,160,176-179 
INDEX DATA SET 22,88,170,175-178 
INDEX DATA SET, SEARCH OF TEE 176 
INDEX DATA SETS, MULTIPLE LEVELS OF 177 
INDEX DATA, USE OF AN 177 
INDEX HIERARCHY 176-178 
INDEX RECORD 178 
INDEX, LEVEL OF 178 
INDEXA 91 
INDEXAB 91-92 
INDICATION, EOD 234 

INDICATOR 50,74,83,159,171-174,178,183 
INDICATOR DS 166 
INDICATOR, BIT TYPE 172 
INDICATOR, DISPLACEMENT TYPE 
INDICATOR, INVREQ 184 
INDICATORS, BIT TYPE SEGMENT 
INDICATORS, DISPLACEMENT 
INDICATORS, TYPE SEGMENT 
INDIRECT ACCESS HIERARCHY 
INDIRECT ACCESSING FEATURE 



23,47-48,55,66,124 



137, 140, 142, 145-146, 150 



172 

172 
173 
172 
176 
175 
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INDIRECT ACCESSING HIERARCHY 22,170 

INDIVIDUAL FIELDS 200-201 

INFORMATION BLOCK 197 

INFORMATION DISPLAY SYSTEM COMPONENT DESCRIPTION 

INFORMATION, BLOCK REFERENCE 180 

INFORMATION, CONTROL 47 

INFORMATION, INPUT/ OUTPUT AREAS 13 

INFORMATION, MASTER RECORD 176 

INFORMATION, USER-CONSTRUCTED 178 

INITIAL TIOA 81 

INITIAL, CONTINUE READ 154 

INITIAL, WRITE 75,154 

INITIALIZATION 1,22,58 

INITIALIZATION REQUEST 155 

INITIALIZATION, SYSTEM 254 

INITIATE BROWSE 102-103,105 

INITIATE NEW TASK 48 

INITIATE REQUESTS 141-142 

INITIATED TASK 144 

INITIATION 2,24,33,40,115,132 

INITIATION OF TRANSIENT DATS CONTROL 48 

INITIATION REQUEST 148 

INITIATION SERVICES AVAILABLE 141 

INITIATION, AUTOMATIC TASK 146,148 

INITIATION, REQUEST TASK 143-144,146-147 

INITIATION, TASK 47 

INITIMG, USE OF THE 202 

INPUT BUFFER 154 

INPUT BUFFER, SIZE OF THE 

INPUT DATA, LENGTH OF THE 

INPUT DET FIELD 201 

INPUT FIELD, FORMAT OF AN 

INPUT FIELDS 200-201 

INPUT MAP FIELDS 2 00 

INPUT MAP GENERATION 19 8 

INPUT MAPPING REQUEST 253 

INPUT PROCESSOR 165 

INPUT STREAM 167 

INPUT/OUTPUT, SYNCHRONIZE TERMINAL 74,83 

INPUT, BATCH 78 

INPUT, PHYSICAL 74 

INPUT, READ/WRITE 2 05 

INPUT, RECEIPT OF 155 

INQUIRY 1,86,88 

INQUIRY, END OF 165 

INQUIRY, HIGH-PRIORITY 125 

INSERT 47,159-160,183,199 

INSERT RECORDS 167 

INSTRUCTION OI TWAIND 

INSTRUCTION, ABEND MACRO 

INSTRUCTION, ATTACH MACRO 

INSTRUCTION, CANCEL MACRO 

INSTRUCTION, CHAP MACRO 

INSTRUCTION, CHECK MACRO 

INSTRUCTION, CICS DFHMDI MACRO 

INSTRUCTION, CONVERSE MACRO 83 

INSTRUCTION, COPY MACRO 77 

INSTRUCTION, DELETE MACRO 19,65-66 

INSTRUCTION, DFHBMS MACRO 202-203 

INSTRUCTION, DFHCOVER MACRO 10 



154 
195 



201 



166 
19,67 
47,66 

137,150,152 
49 
87,93,96,98,111,122,130,151,153,189 
194 



69-71 
50,83,136-138,140 

69,77,79-80 
64 
67,82 



INSTRUCTION, TRANSACTION MACRO 69-70,72 

INSTRUCTION, TRANSIENT DATA MANAGEMENT MACRO 115 

INSTRUCTION, UPDATE MACRO 92*93 

INSTRUCTION, USER MACRO 37,43,217 

INSTRUCTION, VALUE MACRO 

INSTRUCTION, WAIT MACRO 

INSTRUCTION, WRITE 81 

INSTRUCTION, WRITE MACRO 

INSTRUCTION, XCTL MACRO 

INSTRUCTION, YES MACRO 

INSTRUCTIONS, DFHMDF MACRO 195-196,200,202 

INSTRUCTIONS, DL/I DFHFC MACRO 193 

INSTRUCTIONS, FIELD DEFINITION MACRO 197 

INSTRUCTIONS, ISSUING CICS MACRO 6 

INSTRUCTIONS, SUBSEQUENT BFETC MACRO 78 

INSTRUCTIONS, TERMINAL CONTROL MACRO 205 

INSTRUCTIONS, THROUGH MACRO 46 

INSTRUCTIONS, TRACE TASK CONTROL MACRO 216 

INTERFACE, CICS-DL/I 230 

INTERFACE, DB/DC 4 

INTERRUPT 124,154-156,158 

INTEPRUPT, HARDWARE 165 

INTERRUPT, TIME OF 25 3 

INTERVAL CONTROL MACRO INSTRUCTION, USE OF THE 132 

INTERVAL CCNTF.OL POST REQUEST 150 

INTERVAL CONTROL REQUEST/RESPONSE 23 

INTERVAL CCNTRCL WAIT REQUEST 150 

INTERVAL OF TIME 136 

INTERVAL OF TIME GIVEN 143-144 

INTERVALS OF TIME 132,136,139,142,145 

INTRAPARTITION 114,116,118,122 

TNTRAPARTITION DATA SET 119 

INTRVAL 132,136-145,224,248 

INVALID REQUEST 112,160 

INVREQ 141 ,144,147,149, 151-153, 183-184,187-189 

INVREQ KEYWORD, DISCUSSION OF THE 98 

IOKEY 194 

IOLT 156 

IPL 157 

ISAM 41,83,87,93,100,104,170,177,180 

ISAM DATA SET 101,10 4 

ISAM, INDIRECT ACCESS HIERARCHY OF .88 

ISRT 194 

JRNLCR 164 

KEY 89-91,102-103,105,109 

KEYBOARD 76-78,199,204 

KEYC 109-110 

KEYED DATA, LENGTH OF THE 196 

KEYLEN 176 

KEYWORD 126-127,129,134,13 6,139,141,145,14 8,150-151 

KEYWORD, CURSOR 262 

KEYWORD, INITIMG 96 

KEYWORD, RETMETH 88 

L 29,78 

L WRITE 78 

LA 191 

LAYOUT OF THE CONTROL 13 

LAYOUT OF THE CWA 33 

LAYOUT OF THE INPUT/OUTPUT, USIR DEFINED 27 

LAYOUT, DEFINE RECORD 89-90,92,95,97,99,103,106,108 



INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 



56-58,167,202 



INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION. 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION 
INSTRUCTION, 
INSTRUCTION, 



DFHDC MACRO 
DFHFC MACRO 
DFHIC MACRO 
DFHKC MACRO 
DFHPC MACRO 
DFHSC MACRO 
DFHTC MACRO 
DFHTD MACRO 
DFHTS MACRO 
DISCONNECT MACRO 
DISP MACRO 50 
DL/I MACRO 185 
DUMP MANAGEMENT MACRO 
E-TYPE OS CALL MACRO 
ENQ MACRO 53 
FILE MANAGEMENT MACRO 
FOLLOWING MACRO 
FREEMAIN MACRO 
GETAREA MACRO 
GETIME MACRO 
GETMAIN MACRO 



69,80 

23,84, 100,111, 1£ 

132,151 ,153 



56-57,79 

24,74,77-78,154,16 
23,115,122 
125,130 
155 



84 
187,197,199 
19-20,59,98,111 
92,95-96 
134-135 
19,22-23,22,32,34 



GETNEXT MACRO 
INITIAL MACRO 
INITIATE MACRO 
ISSUE ESETL MACRO 



22,99,101,104 
197 
141-143 
107 



ISSUE RESETL MACRO 109-110 

LINK MACRO 19,63,66 

LIST MACRO 51 

LOAD MACRO 65 

MAP MACRO 

NAME MACRO 

NEWREC MACRO 

NEXT SEQUENTIAL 

NO MACRO 6 5-66 

NOPURGE MACRO 

NUMBER MACRO 5 

PAGE MACRO 83 

PARTIAL MACRO 

PASSBK MACRO 

PIO 157 

POST MACRO 138-140 

PROGRAM MANAGEMENT MACRO 

PURGE MACRO 

RELEASE MACRO 

RESETL MACRO 

RETRY MACRO 

RETURN MACRO 

SEGMENT MACRO 

SETL MACRO 



256 
47,63-64,66 
182 



21,71 
161 



55,121 

87,98,111 
101,108 
152 
47,63,66 
73 



22,100-101,103-104 
SPECIAL INITIALIZATION MACRO 
STORAGE CONTROL GETMAIN MACRO 
STORAGE MANAGEMENT MACRO 56 
TASK MANAGEMENT MACRO 46 
TEMPORARY STORAGE MANAGEMENT MACRO 
TEMPSTRG MACRO 56 
TERMINAL MACRO 5 9,79 
TERMINAL MANAGEMENT MACRO 74 
TRACE CONTROL MACRO 216 
TRANSACTION CODE MACRO 66 



78 



LENGTH VALUE 200,257 

LENGTH, BLOCK 183 

LENGTH, MOVE 117,127 

LINE 81 

LINEADR 75,77,157-158,245 

LINKAGE SECTION BASE LOCATOR 32 

LINKAGE SECTION, START OF 3 8 

LISTADDR 5 2 

LISTING OF ANS COBOL FEATURES 32 

LISTNAME 185 

LL 116,125,146,171 

LLBB 116-118,125,146,149,167,171,174 

LOADLST 61,65-67,244 

LOCATION TCAPCAER 251 

LOCATION TCATDAA 117 

LOCATION TCATDDI 117,119,121 

LOCATION, USER- SPECIFIED 134 

LOCATOR 20 8 

LOGIC, MAINSTREAM 234 

LOGICAL 7, 13, 6 6, 83, 102, 158, 16 C, 170-171,174-177 

LOGICAL CLOSE 74 

LOGICAL LIMIT 

LOGICAL LOOP 

LOGICAL RECORD 

LOGICAL RELATIONSHIP 

LOGICAL WRITE 160 

LRECL 1 76 

MACRO INSTRUCTIONS 243 

MACRO, DFHCOVER 10 

MACRO, ISSUE INITIAL SETL 

MACRO, ISSUE RESETL 109 

MACRO, TLIST 77 

MANAGEMENT, 

AUTOMATIC TASK INITIATION FEATURE OF CICS TIME 
MANAGEMENT, COMMUNICATION LINE 1 54 
MANAGEMENT, DYNAMIC PROGRAM 1 
MANAGEMENT, FILE 2,23,174,178 
MANAGEMENT, SEQUENTIAL DATA 2 
MANAGEMENT, TASK 1 

MANAGEMENT, TEMPORARY STORAGE 2,23,46 
MANAGEMENT, TIME 1,23,46 
MANAGEMENT, TRANSIENT DATA 2 
MAP 174,194,196,195-207 
MAP DFHMDF MACRO INSTRUCTIONS, 

FIELDS OF THE INPUT 203 
MAP FORMAT 194,196,195 



176 
132 
(,88,101,103-104,158,160,170-172,177,181 
169 



109 



MAP GENERATION 
MAP OPERATION 
MAP SPECIFICATION 
MAP, INPUT/OUTPUT 
MAP, OUTPUT FIELD 
MAP, PHYSICAL 



197 
198,205 

258,263 
201 
201 
194,196,195,197 



MAPADR 203,205 

MAPPING 19 7 

MAPPING OPERATION, TYPE OF 203 

MAPS, BMS 203 

MAPS, INPUT 195-196,199 

MAPS, OUTPUT 195,199-201,203-204 

MAPS, TYPES OF 194 

MAPI 197-198 
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MAP2 198 

MASTERA 89-92 

MAXIMUM DATA LENGTH 195 

MAXIMUM LENGTH 19 5-196 

MAXIMUM MESSAGE LENGTH 76 

MBBCCHHR 101 

MD 166-167,201 

MDT'S 199,201,206 

MED 179 

MESSAGE AREA, USER DEFINEE LAYOUT OF THE 26 

MESSAGE DFHTS 126 

MESSAGE, HEADERS 155 

MESSAGE, CRDR TRANSACTION- INVOKING 167 

MESSAGE, DESTINATION OF THE 78 

MESSAGE, ERROR 76,159 

MESSAGE, INPUT 15 4,160 

MESSAGE, INVALID TERMINAL IDENTIFICATION 157 

MESSAGE, LOGICAL 160 

MESSAGE, LOGICAL LENGTH OF THE 160 

MESSAGE, OPERATOR 45 

MESSAGE, OUTPUT 25,76,78,158,160 

MESSAGE, PSEUDO-ABEND 184 

MESSAGE, SAVES 3 9 

MESSAGE, STATUS 166 

MESSAGE, TRANSMIT 156 

MESSAGE, WRITES 29,39 

MESSAGE, ASSEMBLY ERROR 255 

MESSAGE, ROUTE 77 

METHOD, DIRECT ACCESS 83 

METHOD, GRAPHICS ACCESS 7 4 

METHOD, INDEXED SEQUENTIAL ACCESS 83 

METHOD, TELECOMMUNICATIONS ACCESS 74 

MF 186 

MIDNIGHT 133,135 

MIGRATION PATH 4 

MINIMUM 136,139,142,145,171 

MODE 125,197-199,202,205 

MODIFIED DATA TAGS 7 6,199,201,204 

MOVE STATEMENT, USE OF THE 32 

MSGLITE 164 

NEWREC 85,92,96-97 

NONZERO 172-173 

NONZERO TRIGGER LEVEL 115 

NOPURGE 47 

NORESP 152,184,187-189,191 

NORESP, DICUSSION OF THE 120 

NORM 199-20 

NORMAL INTENSITY 200 

NOSPACE 85,92-93,110-112,115-116,123,122-123 

NOSTRG 57-58 

NOTOPEN 115-116,118,120,123,122-123,187-189 

NOTR ANSI AT E 75,245 

NULL CHARACTER 197 

NULLS 75-77,196 

NUM ATTRIBUTES 200 

NUMERIC VALUE 136,139,141-142,146,145 

OFFLINE 68,194,196 

OFFLINE MAP BUILDING 197 

ONLINE 199 

ONLINE SYSTEMS 1 



PDIR 1 84 

PEQU 156 

PERFORMANCE, DEGRADATION OF 76 

PERFORMANCE, EVALUATION- SYSTEM 46 

PERFORMANCE, SYSTEM 6 

PHYSICAL 124,180-182 

PHYSICAL BLOCK 10 2 

PHYSICAL DATA RECORD 144 

PHYSICAL KEY 180-181 

PHYSICAL RECORD 181 

PL/I 164,185-186,193,19 5,198,20 5,20 8-2 09,219,231,243 

PL/I APPLICATION PROGRAM, EXAMPLE OF CICS 44 

PL/I APPLICATION PROGRAMMING 39 

PL/I COMPILE 10 

PL/I EXAMPLE 163,240 

PL/I F 252 

PL/I FEATURES, LISTING OF 3 9 

PL/I OPTIMIZING COMPILER 2 52 

PL/I SUPPORT 2 52 

PLITDLI, CALL 187,194 

POINTER 31,48,187,191-193 

POINTER VARIABLE 198 

POINTER, BLL 185,1-91 

POLLING .74,79 

POOL, DMB 184 

POOLS 184,189 

POS 199-200,202 

PRIMARY DATA SET 176-179 

PRIMARY LATA SET, SYMBOLIC NAME OF THE 87 

PRINT 200,199,204 

PRINTER 190,195,199-200,204 

PRINTER CONTROL CHARACTERS 2 06 

PRINTERS, LINE 2,214 

PRIORITY 11,45-49,24 3 

PRIORITY OF A TASK 46, 48-49 

PRIORITY OF AN EXISTING TASK, DISPATCHING 48 

PRIORITY SEQUENCE 47 

PRIORITY VALUE 48-49 

PRIORITY, DISPATCHING 18 

PRIORITY, NORMAL DISPATCHING 150 

PROCEDURE DIVISION, START OF 38 

PROCESSING, QUEUE 123 

PROGRAM ASSEMBLY ERRORS, SEVERITY OF 255 

PROGRAM CATLOG 176 

PROGRAM CHANGES 214 

PROGRAM CHECK 1,253 

PROGRAM COINCIDE, EXIT POINTS OF A 60 

PROGRAM CONTROL 46,60,6 3-64,66,215,223,252,254 

PROGRAM CONTROL LOAD 305 

PROGRAM .CONTROL TABLE 23,46,55,152 

PROGRAM CONTROL TABLE ENTRY 23 

PROGRAM ENTRY 9,191 

PROGRAM FLOW 111^122,130,152 

PROGRAM INTERRUPT 253 

PROGRAM INTERRUPT MANAGEMENT 1 

PROGRAM INTERRUPTS, INTERCEPTION OF 1 

PROGRAK LINKAGE 61 

PROGRAM LOAD AREAS 55 

PROGRAM MAINTENANCE 114 

PROGRAM MANAGEMENT 1,60 



OPERATOR REPLY 29,38-39,45 

OPERATOR, CONSOLE 133-134 

ORDERED REQUEST 150 

ORIGINATING TASK 124,150 

ORIGINATING TASK RESUMES CONTROL 150 

OS 133,180 

OS ISAM FILLER NAME 26 

OS/360 50 

OUT 198,203 

OUTPUT 76,125, 155,158,165,197,200,203 

OUTPUT MAP DESCRIPTION 204 

OUTPUT MAP FIELDS 204 

OUTPUT MAP FORMATS 194 

OUTPUT GENERATION 198 

OUTPUT MAP, ATTRIBUTES OF AN 195 

OUTPUT MAPPING FUNCTIONS 2 04 

OVERLOAD CONDITIONS 55 

OVERLOAD, SYSTEM 4 6,55-56 

PACKTIME 140,147 

PARAMETER LIST 185 

PARAMETER, BLKKEYL 180 

PARAMETER, CBUFF 76 

PARAMETER, DATASET KEYWORD 92,95 

PARAMETER, DISCONNECT 75 

PARAMETER, ERASE 8 2 

PARAMETER, ERASEAUP 76 

PARAMETER, OPTIONAL 1«6 

PARAMETER, PASSBK 76 

PARAMETER, PSEUDOBIN 78,156,158 

PARAMETER, READB 7 5-T.o-. 

PARAMETER, RESET 75 

PARAMETER, SAVE 8 1 

PARAMETER, SEGSET KEYWORD 86,92 

PARAMETER, SSACOUNT 187 

PARAMETER, TRANSPARENT 77 

PARAMETER, WAIT 80,83 

PARAMETER, 3270 KEYWORD 198 

PARAMETERS, DISCUSSION OF THE 71 

PARAMETERS, INDEX KEYWORD 86 

PARAMETERS, PASSING OF 17 

PARAMETERS, STAND-ALONE 7 5 

PARAMETERS, WRITEL 78, 82 

PARENTHESES 11,185,188 

PARMCOUNT' 186-187 

PASSBOOK 76,159-161 

PASSBOOK CONTROL 159-161 

PASSBOOK INDEXING 160 

PASSBOOK PRESENT 163 

PASSBOOK WRITE 160 

PASSBOOK, BANKING 76 

PASSBOOK, FOSITICN OF THE 160 

PASSBOOK, PRESENCE OF A 74,160,163 

PCB DSECT 190 

PCB POINTERS 183,190,193-194 

PCB POINTERS, E7ASE OF A STRUCTURE OF 193 

PCB POINTERS, DECLARED STRUCTURE OF 193 

PCB POINTERS, LAYOUT OF THE 191 

PCB'S 183-184, 1B6-194 

PCB' S OF PSB 1 90 

PCT 46,55,152,184 



PROGRAM MANAGEMENT DUMP SERVICES 46 

PROGRAM NAME SUFFIX 16 5 

PROGRAM PROCESSING TABLE 56 

PROGRAM SERVICES 60 

PROGRAM SPECIFICATION BLOCK . 183 

PROGRAM TESTING AND DEBUGGING 214 

PROGRAM, CICS TERMINAL ABNORMAL CONDITION 115 

PROGRAM, CICS UTILITY 1,68 

PROGRAM, CONVERSATIONAL 1 89 

PROGRAM, INTERVAL CONTROL 153 

PROGRAM, SERIALLY REUSABLE APPLICATION 6 

PROGRAM, SUSPENDING 56 

PROGRAM, TERMINAL ABNORMAL CONDITION 73 

PROGRAM, TERMINAL CONTROL 78,160 

PROGRAM, TERMINAL ERROR 73 

PROGRAM, TRACE 216,220 

PROGRAM, TRANSACTION CONTROL 251 

PROGRAM, TFANSIENT DATA CONTROL 118 

PROGRAMMER, RESPONSIBILITY OF THE 186 

PROGRAMMER, SYSTEM 4 

PROGRAMS, APPLICATION 180,183,190,194-195,197, 

199,2 02-203,20 5,215,254 
PROGRAMS, CICS MANAGEMENT 18,46,48,55,215,220 

PROGRAMS, HIGH-LEVEL LANGUAGE 161 

PROGRAMS, RECOMPILING EXISTING 114 

PROGRAMS, USER APPLICATION 6,18-19,21-22,55,59,214 

PROGRAMS, USER-WRITTEN APPLICATION 60-61,63-64, 

69-72,74,154,199,201,205,214 
PROT ATTRIBUTE 200 

PRTY 47-49,243 
PSB 183-184,188-190,192,249 
PASB DIRECTORY 184 

PSB POOL 184 

PSBGEN 184 

PSENAME 184,249 

PSEUDOBIN 75,81,156,245 

PURGE 46-47,55-56,116,121,22 8,244,247 

PURGE/NOPURGE 55 

PWRI 157 

QARGADR 47,52-54,244 
QARGLNG 47,52-54,244 
QUASI-REENTRANCE 6,29,60,183 

QUASI-REENTRANT 39,45,190 

QUEUE 56,114-115,121-123,144,221,231,251 

QUEUE, INTRAPARTITION 1 23 

QUEUES, EXTRAPARTITION INPUT 122 
RDIDADR OPERAND, DISCUSSION OF THE 180 

READ-ONLY 8 4,174 

READ/WAIT 2 02 

READL 75,78,245 

READREC 89-92 
READUPD 94 
REENTRANCE 38 

REENTRANCE ALLOWS 6,60 

REENTRANT 39,44,124,183,240 

REFRESH 223 
REFRESH CSA TIME 224 

REGISTER, ASSIGN BASE 98,102 

REGISTER, BASE 89-91,94,96,98 

RELATIVE BIOCK 180,182 
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RELATIVE POSITION 185 

RELATIVE RECORD 88 

RELATIVE RECORD NUMBER 181 

RELATIVE TRACK 102,180-181 

RELATIVE TRACK KEY 181 

RELBLK 181 

RELEASE REQUEST 98-99 

RELREC 81-85,87,99, 102, 245-246 

RELTYPE 180 

REQID 132, 134, 136-142, 144-147,149-150,248 

REQUEST 98,120-121,150-151,19 0,253 

RESET ACCA 157 

RESET, WRITE 154-155 

RESETL 85,108-110,112,227,246 

RESPONSE CCDES, TESTING OF 110,123,130,151 

RESPONSE, END-OF-DATA 148 

RESPONSE, EOT 154 

RESPONSE, I/O ERROR 151 

RESPONSE, NORMAL 111,122,130,152 

RESPONSE, NORMAL END-OF-FILE 152 

RESPONSE, NOSPACE 123 

RESPONSE, OPERATOR 189 

RETMETH 84-85,87-88,99,101-102,245-246 

RETRIEVAL CALL 186 

RETRIEVAL CF A TIME-ORDERED EATA RECORD 149 

RETRIEVAL THROUGH 152 

RETRIEVAL, ESETL RESET SEQUENTIAL 108 

RETRIEVAL, RANDOM 2 

RETRIEVAL, SELECTIVE 2 

RETRIEVAL, SEQUENTIAL 100,113 

RETRIEVAL, TERMINATE SEQUENTIAL 106 

RETRY REQUESTS 152 

REUSABLE 1 14 

REUSABLE RESOURCES, CONTROL OF SERIALLY 1 ,52 

REUSABLE STORAGE SPACE 124 

REUSABLE, SERIALLY 6,60,124 

ROLLOUT 32 

ROOT 172 

ROUTINE, EFROR 10 2 

ROUTINE, EXIT 165-166,168,167-169 

ROUTINE, SERVICE 215 

ROUTINE, USER-WRITTEN EXIT 166 

ROUTINES, ETAM ERROR 157 

RSA'S 70,72 

RVI 154 

SAA 14,28,37,43,58,186 

SAACBAR 28,37 

SAMPLE PROGRAMS 231 

SCHEDULING PROCESS 183 

SCREEN FORMATS 195 

SCREEN IMAGES 124 

SEGIDER 84-85,87,99-100,103,108,110-111 ,245-246 

SEGMENT DEFINITIONS 171 

SEGMENT INDICATOR FIELD 172 

SEGMENT INDICATORS 171-172 

SEGMENT INDICATORS, SEGMENT DISPLACEMENT TYPE 172 

SEGMENT SEARCH ARGUMENTS 183-185 

SEGMENT SEARCH ARGUMENTS, NAMES CF 187 

SEGMENT SET IDENTIFICATION 22 

SEGMENT SET NAME 101,104,175 



STORAGE, AUXILIARY 124-127,129-131,152 

STORAGE, AUXILIARY TEMPORARY 124 

STORAGE, CICS 70,187 

STORAGE, CICS DYNAMIC 183 

STORAGE, CLASS OF 57-58 

STORAGE, CONSERVATION OF MAIN 2 

STORAGE, DUMP TRANSACTION 69 

STORAGE, DYNAMIC 13,169,185 

STORAGE, FREE 118 

STORAGE, PROGRAM 56 

STORAGE, RELEASE ALL TERMINAL 59 

STORAGE, RELEASE MAIN 59 

STORAGE, SSA DYNAMIC 185 

STORAGE, STATIC 183,190 

STORAGE, SYMBOLIC 125 

STORAGE, TEMPORARY 27,36,43,12 4-130 

STORAGE, TEMPORARY STORAGE AUXILIARY 124 

STORAGE, TERMINAL 39,45,56,59 

STORAGE, TRANSACTION 56,124,127 

STXIT 11 

STYPE 216-218,249 

SUPERVISORY, SERVICE INVOCATION CICS PROVIDES 4 6 

SUSPEND 221,234 

SUSPENDED TASKS 56,129 

SUSPENSION OF A TASK 137 

SVC 11 

SWITCHED LINES 75 

SYMBOL, START 82 

SYMBOLIC DESCRIPTION MAP 194,196-197 

SYMBOLIC DESTINATION 114,117,119,121 

SYMBOLIC DESTINATION IDENTIFICATION 122,130 

SYMBOLIC LABELS 196 

SYMBOLIC REFERENCES 114,199 

SYMBOLIC STORAGE DEFINITION MAP 196 

SYMBOLIC TERMINAL IBENTIFTCSTION 143,146,152 

SYMBOLIC TRANSACTION IDENTIFICATION 142-144,146,152 

SYMDMP 1 1 

SYNCHRONIZATION, LINE 71* 

SYNCHRONIZATION, PROVIDE TASK 132 

SYNCHRONIZATION, TASK 1 ,50 

SYNCHRONIZATION, WRITE 203 

SYSOUT 74 

SYSTEM INITIALIZATION 13 

SYSTEM/7 77-78,156-157 

SYSTEM/7 SUPPORT, I IMPLEMENTATION OF 156 

SYSTEM/7, DIAL-UP 157 

SYSTEM/7, MULTIPOINT 156 

TABLE, ALLOCATED TERMINAL CONTRCL 24,33,39 

TABLE, CORRECT TRANSLATE 161 

TABLE, PROCESSING PROGRAM 19,63-65,203,205 

TABLE, TRACE 69,71-73,215-216,218,217-219 

TABLES, TRANSLATE 264 

TAPE 1-2,68,114 

TASK 11,13,50,68,252 

TASK CCNTRCL, USE OF THE 66 

TASK MANAGEMENT SERVICES 1 8 

TASK MANAGEMENT STORAGE SERVICES 46 

TASK OF HIGHER PRIORITY 5 

TCA -144,147-149, 151, 166-167,182,190,215,221,251-254 

TCA FLAG 216 



SEGMENT SET, SYMBOLIC NAME CF THE 87,101,108 

SEGMENT SETS 86,92,100-101,104,170,172-175 

SEGMENT, FIXED-LENGTH 171 

SEGMENT, SCOT 171-174 

SEGMENTATION 1 1 

SEGMENTED DATA SET 88,170,173-175 

SEGMENTED RECORD 26,42,8 6-88,92-93,101,169-171,173-174 

SEGMENTED RECORDS, USE OF 170 

SEGMENTS, VARIABLE-LENGTH 174 

SEQUENTIAL ACCESS METHOD 74,214 

SEQUENTIAL DATA SET 1,68 

SEQUENTIAL RECORD 10 4,106,105-106,114 

SERVICE INVOCATION 1 1 

SERVICES, TASK 46 

SERVICES, TIME 132 

SERVICES, TIME-OP-DAY 134 

SERVICES, TRANSIENT DATA 120-121 

SETL 22,85,99-100, 10 2-10 3,105-106,108-110,227,246 

SETL REQUEST 99-100,104,108 

SHIFT CHARACTERS 76,160 

SIGN ON/SIGN OFF 154 

SINGLE-SERVER 52 

SINGLE-SERVER RESOURCE PROTECTION PEQCESTS 53 

SKIP 108 

SKIP, AUTO 196 

SLACK 172 

SORT 11 

SPECIFICATION OF ATTRIBUTES 2 59 

SPECIFICATION, PRINTER FORMAT 255 

SPECIFICATION, RECORD FORMAT 114 

SSA DFHSC TYPE 190 

SSA LIST 188,230 

SSA LIST, DESCRIPTION OF THE 187 

SSA-COUNT 193 

SSA'S 18 3-185,187-188,191,193-194,193,195,194,250 

SSA'S, NUMBER OF 185,187 

SSACOUNT 185,187,250 

SSALIST 185,187-188,191,250 

STALL CONDITION 252 

STALL CONDITION, SYMPTOMS OF A SYSTEM 132 

STANDARD ATTENTION IDENTIFIER LIST 2 06 

STANDARD ATTRIBUTE LIST 206 

STANDARD EXIT ROUTINE BASE NAME 167 

STANDARD POSTING CONVENTIONS 50-51 

STATEMENT NUMBER 29,31,38,45 

STATEMENT, SERVICE RELOAD 32 

STATISTICS 18 

STATISTICS ACCUMULATOR 17 

STATISTICS, TIME SYSTEM 2 

STORAGE ACCOUNTING AREA 19,37,43,58 

STORAGE ACQUISITION 1 

STORAGE ACQUISITION REQUEST 56 

STORAGE ALIGNMENT 234 

STORAGE AREAS, ATTRIBUTES OF TEE 39 

STORAGE AREAS, NUMBER OF MAIN 13 

STORAGE AREAS, TYPES OF 71-72 

STORAGE CONTROL 55-56,169,202,215,222,253 

STORAGE MANAGEMENT 1 

STORAGE PREFIX 192 

STORAGE, ACQUIRE 183,187,190,192,194 



TCA STRUCTURE, DECLARATION OF TEE 4 

TCA, CHAIN OF 18 

TCA, CICS CONTROL SECTION OF THE 22 

TCA, CICS SYSTEM CONTROL SECTION OF TEE 25 

TCA, COMMUNICATION SECTION OF THE 25 

TCA, DISCUSSION OF THE 47 

TCA, EXTENSION OF THE 2 3 

TCA, FIELDS OF THE 18,100,107-108 

TCA, REQUESTING PROGRAM 215 

TCA, REQUESTING TASK 69 

TCA, TASK 2 53 

TCABMSCP 204 

TCABMSMA 205 

TCABMSMN 204-205 

TCACBAR -34,3 8,54,89-91,94,97,99,103,10 5,110,238 

TCACSIB 57 

TCADCNB 73 

TCADCSA 73 

TCADCTR 226 

TCADLECB 18 4,254 

TCADLFUN 191,193-194 

TCADLIO 187,186-187,191,194 

TCADLPCB 184,189-191,193-194,230 

TCADLPSB FIELD 184 

TCADLSSA 185,188,191 

TCAFCAA 22,41-42,87,89-100, 102-112,182 

TCAFCAAA 18,79-80,233,210 

TCAFCAI 22 

TCAECDI 22,111 

TCAFCRC 87,93,96,98,110-111,113 

TCAFCRI 22 

TCAFCSI 22,104,111 

TCAFCTR 23,87,93,96,98,110-111 ,113,227,230 

TCAFCURL 9 3,18 2 

TCAICDA 135,146-147,149,151 

TCAICQID 137-138, 140,142-144,147,150-152,225 

TCAICRC 144,143,146,148,151,224 

TCAICRT 137-138,140,143,147,224 

TCAICTEC FIELD 138 

TCAICTI 143-144,146-147,224 

TCAICTID 113-144,146-147 

TCAICTR 23,144,143,146,148,151,223-225 

TCAKCFA 48 

TCAKCTI 48 

TCAM 74,77,81-82 

TCAM DESTINATION NAME 78 

TCAM MCP 77 

TCANXTID 66 

TCAPCAC 19,67-68 

TCAPCLA 65 

TCAPCPI 19,63-67,253 

TCAPCTR 252 

TCASCIB 22,57-58 

TCASCNB 21-22,57-58 

TCASCSA FIELD 19,58 

TCASCSA 27 29 

TCASYAA 25 

TCATCDP 49 

TCATCEA 51-52 

TCATCQA 53-55 
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TCATCQAL 5 5 

TCATDAA 27,1*2,118-119,228,235,2111 

TCATDAA, CONTENTS OF 119 



TCATDDI 

TCATDRC 

TCATDTR 

TCATSDA 

TCATSDI 

TCATSRC 

TCATSTR 

TCT 

TCTLE 

TCTTE 

TCTTEAID 

TCTTEAR 

TCTTEOS 

TCTTEPCF 

TCTTEPCR 

TCTTEPCW 

TCTTESC FIELD 

TCTTESID 

TCTTETAB 

TCTTETI FIELD 

TCTTETID FIELD 
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129,233,235 
130-131 

23,130-131,228 
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81-82 
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168 
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159,163-164 

56 
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TCTTETM 

TDADDR 

TDIA 

TDIAEAA 

TDIABAB 

TDIABAR 

TEIADBA 

TDIAIRL 

TDOA 

TDOABAR 

TDOAVRL 



161 



27,115-118,234-235,238-239,241,24 6 
14,26,35-36,42,58-59 

120 

120 

36,42, 119-120,235,239,241 

241 

235,241 
14,27,36,42-43,58-59 

27,36,116-117 

27,117-118 
TEMPORARY EATA, RETENTION OF 17 

TEMPORARY STORAGE CONTROL REQUEST/RESPONSE 23 

TEMPORARY STORAGE SERVICES 125-127,129-130 

TERMINAL CONTROL 24,74,79-82,202-203,2 05 

TERMINAL CCNTRCL TABLE 39,45,74,81,152,161,214 

TERMINAL CONTROL TABLE, PREPARATION OF THE 154 

TERMINAL CONTROL WRITES 80 

TERMINAL ID 143-144,147,221 

TERMINAL IDENTIFICATION 124,146,148,157 

TERMINAL INPUT RECORDS 34,41 

TERMINAL INPUT/OUTPUT 59 

TERMINAL INPUT, USER DEFINITION OF A 25 

TERMINAL LOG 1 1 5 

TERMINAL MANAGEMENT 1,74 

TERMINAL MANAGEMENT FILE SERVICES 46 

TERMINAL, DESTINATION 1 68 

TERMINAL, MASTER 77,115,154 

TERMINAL, OUTPUT 168 

TERMINALS, BINARY SYNCHRONOUS 
TERMINALS, KEY-DRIVEN 74 

TERMINALS, LIST OF 77 

TERMINALS, POINT-TO-POINT 
TERMINALS, SIMULATION OF 
TERMINALS, 2260 74,81 

TERMINATION, SYSTEM 229 
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TWANXREC 

TWAQEMCI 

TWAREAI 

TWAREC 

TWATDDI 

TWATSRL 

TWAWA 

TWAXTRTN 
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TTR, ZONED 181 

TWA 71-73,81,89-92,94-95,97,102,105-106,109 

TWA, LAYOUT OF THE 34 

TWA, SIZE OF THE 23 

TWAFIELD 3 1 

169 
236,239,241 

235,239,241 
166-169 

233-235,238-241 

233-234 
167-169 

166-167,169 
TWAXTRTN, MODIFICATION OF THE 166,168 

TXA 69,71-73,221 

TYPOPER 84-85,87-88,90-97,111,245 

UNDEFINED RECORDS 83,182 

UNIVERSAL SEGMENT SET 175 

UPDATE REQUEST 88 

UPDATE, RESULT OF AN 171 

UPDATED RECORD 94-9 5 

UPDATING SEGMENT TYPES 183 

USER EXITS 165-166 

USER EXITS, USE OF THE 165 

ESER FIELDS 20 4 

USER PROGRAM REGISTERS 9 

USER STATISTICS ACCUMULATORS 4 17 

USER STORAGE, DEFINITION OF 43 

USER TERMINATION CODE 19 

USER-DEFINED 55,167,176,178 

UTILITIES, OPERATING SYSTEM 214 

VARIABLE LENGTH 114,116-117,171 

VARIABLE LENGTH RECORDS 18 3 

VARIABLE-LENGTH 168,170,182 

VARIABLE-LENGTH EATA SETS 118 

VARIABLE-LENGTH RECORDS 83,114,118,170-171,174,181 
VARIABLE-LENGTH SEGMENT, MAXIMUM LENGTH OF A 171 

VARIABLES, ELEMENTARY CHARACTER 2 06 

VARIABLES, SINGLE-CHARACTER 206 

VIDEO 124 

VIDEO DISPLAY PAGING 2 

WAIT 47,50-52,83,132,135,137-13 8,149-150,203 

WAIT REQUEST 136,152 

WCC 77 

WORKING STORAGE, AMOUNT OF 23 

WORKREG 20-21 

WRITE 38,44,75-78,77-83,156-158 

WRITE CONTROL CHARACTER, 

HEXADECIMAL REPRESENTATION OF THE 77 

WRITE REQUEST 155 

WRITE, COMPLETION OFA 81,2 04 

WRITE, ISSUE 79-80 

WRITEL 75,245 

WRITER, REPORT 11 

XCTL 11,19,61,64,223,244 

ZERO SEVERITY 26 2 

2260 77 

2260 DISFLAY STATION 168 

2265 77 

2721 164 



TESTING INDICATORS TCTTEPCR 159 

TESTING REQUIREMENTS 214 

TESTING, DEBUGGING 214 

TIME 136-137,139-142,145 

TIME MANAGEMENT ALLOWS, FEATURE OF 141 

TIME SERVICES 150-151 

TIME-ORDERED 133 

TIME-ORDERED REQUEST 1 52 

TIME -ORDERED SERVICE REQUEST 149 

TIOA 77-83,156,158,165,167-168,195-196,202-205,207 

TIOA FORMAT 20 2 

TIOA LENGTH 81-82 

TIOA, DUMP OF THE 69,80 

TIOA, MAPPED 203,205 

TIOAEAA 20 8 

TIOABAB 208 

TIOACLCR FIELD 168 

TIOAEBA 76,79-80,234 

TIOAL 81 

TIOALAC 77,158,168 

TIOAMBA 233 

TIOAMSG 38,44 

TIOATDL FIELD 79,167 

TIOATDL 21 29 

TRACE 11,215,219,221-230 

TRACE CONTROL FUNCTIONS 215 

TRACE FEATURE 215,219 

TRACE TABLE 219 

TRANSACTION DUMP 70-71 

TRANSACTION FORMATS 21 4 

TRANSACTION ID 143-144,147,221-230 

TRANSACTION INITIATION 74 

TRANSACTION STORAGE, DUMP OF 70 

TRANSACTION SYNCHRONIZATION 1 

TRANSACTION TCA 184 

TRANSACTION TEST CASES 214 

TRANSACTION TYPE 70 

TRANSACTION, AUTOMATICALLY INITIATED 157 

TRANSACTIONS, TIME-INITIATEE 155 

TRANSDATA 27,56,58-59,244 

TRANSID 47-48,61,6 6,132,134,141-146,243-244,248 

TRANSIENT EATA DESTINATION CSMT 251 

TRANSIENT EATA MANAGEMENT FIELE 23 

TRANSIENT EATA SERVICES 114-115,117,119,121-122 

TRANSLATION 76-77 

TRANSMISSION TIMES 76 

TRANSMISSION, END OF 15 4-155 

TRANSPARENT 75,245 
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TSIOAVRL 

TTR 
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76 
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TRANSLATE TABLES 160-161 

BUFFER LENGTH 160 
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AUDIBLE ALARM SPECIAL FEATURE 

BASIC MAPPING SUPPORT 205 

BUFFER 76,194 

BUFFER, CONTENTS OF THE 75 

DATA BUFFER 199 

DATA STREAM 194-195,2 03,205 

FORMATS, EXPANSION OF THE 19! 

FUNCTION 206 

INFORMATION DISPLAY SYSTEM 

MAP GENERATION 255 

MAPPING SUPPORT 253 

OPERATOR 199,204 
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SCREEN 195 
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